これについてのご意見/ご経験をお聞かせください。
CMS は HTTP_USER_AGENT 文字列から情報を取得しています。最近、コードにバグが発見されました - HTTP_USER_AGENT が存在するかどうかを確認するのを忘れていました (これは可能ですが、正直に言うと、それをスキップしただけで、それが起こるとは予想していませんでした) - これらのケースではエラーが発生しました。HTTP_USER_AGENT が設定されていない場合、アラートが追跡システムに送信されます。
現在、過去数か月の多くのウェブサイトからのデータ/統計があります。現在、私たちの統計は、これが本当にまれであることを示しています. ~ 0.05-0.1%
別の興味深い観察:これらのリクエストは単一です. この「ユーザー」が同じセッションで複数のページビューを持っているケースは見つかりませんでした...
これにより、私たちは考えざるを得なくなりました...これらのリクエストをロボットとして扱うべきですか? そして、単にそれらをブロックします... それとも、それは重大な間違いでしょうか?
Googlebot やその他の「優れたロボット」は常に HTTP_USER_AGENT 情報を送信しています。
ファイアウォールまたはプロキシ サーバーがこのユーザー エージェント情報を変更 (または削除) する可能性があることはわかっています。しかし、私たちの統計によると、これを明確にすることはできません...
あなたの経験は何ですか? このトピックについて調査した人は他にいますか?
私がstackoverflowで見つけた他の投稿は、「この情報が送信されていない可能性がある」という事実を単に受け入れています。しかし、それについて少し質問してみませんか？本当に普通ですか？？
2 に答える
ユーザーエージェントの欠如は、本物のユーザーにとって異常だと思いますが、ファイアウォール、プロキシ、またはプライバシーソフトウェアがユーザーエージェントを削除することが原因である可能性は [まれ] です。
ユーザー エージェントがないリクエストは、ボットまたはスクリプトである可能性が最も高いです (検索エンジン クローラーとは限りません)。もちろん、確かなことは言えませんが。
ボット/スクリプトを示すその他の要因:
- ページ自体をリクエストするだけで、画像、CSS、Javascript などのページ上のリソースをリクエストできない
- ページからページへのリクエスト間の非常に短い間隔 (同じ秒内など)。
- Cookie が設定されているはずの後続のリクエストで、Cookie またはセッション ID の送信に失敗しましたが、正規のユーザーが Cookie を無効にしている可能性があることに注意してください。
それでは、反応に基づいていくつかのことを要約しましょう。
おそらく最善の方法は、すべての可能性を組み合わせることです。:-)
これが最初の (セッション内で十分な) 受信リクエストである場合、複数の基準に対してリクエストをすぐにチェックすることがあります。サーバー側では、動的データベース (ユーザー エージェント情報文字列 / IP アドレスから構築) を持っている場合があります。パブリック データベースをミラーリングすることで、このデータベースを作成できます。(はい、ボットをチェックするためにインターネット上で利用できる、定期的に更新される公開データベースがいくつかあります。それらには、ユーザー エージェント文字列だけでなく、ソース IP も含まれています)
ヒットがある場合は、データベースを使用してすばやくチェックできます。そのフィルターが「OK」の場合、信頼できるボットとしてマークし、リクエストを処理することがあります。
リクエストに利用可能なユーザーエージェント情報がない場合、問題が発生します... (実際、これが私の質問の起源でした)。ユーザー エージェント情報がない場合はどうすればよいですか? :-)
ここで決定を下す必要があります。
これらの要求を単純に拒否する最も簡単な方法は、これが異常であると考えてください。もちろん、この時点から実際のユーザーを失う可能性があります。しかし、私たちの統計によると、それは大きなリスクではないと思います. 人間が読めるメッセージ「申し訳ありませんが、お使いのブラウザはユーザー エージェント情報を送信しないため、リクエストは拒否されました」などを返信することもできます。これがボットの場合、とにかくそれを読む人は誰もいません。これがヒューマノイドである場合、私たちは親切に彼女/彼に有用な指示を与えるかもしれません.
これらのリクエストを拒否しないと決定した場合、MrCode によって提案された事後追跡メカニズムをここで開始することがあります。OK、そのリクエストを処理しますが、動作情報の収集を開始しようとします。どのように？たとえば、db の IP アドレス (グレーリスト) をメモし、応答で偽の CSS ファイルを返します。これは、Web サーバーによって静的に提供されるのではなく、サーバー側の言語 (PHP、Java、または使用しているもの) によって提供されます。これがロボットである場合、CSS ファイルをダウンロードしようとする可能性はほとんどありません... 一方、これが実際のブラウザーである場合は、おそらく非常に短い時間 (たとえば 1 ～ 2 秒) でダウンロードします。偽の CSS ファイルを提供しているアクションのプロセスを簡単に続行できます。graylist db で IP ルックアップを実行するだけで、動作が正常であると判断された場合は、その IP アドレスをホワイトリストに登録できます (たとえば..)
a) 1 ～ 2 秒の時間枠内に再びグレー リストの IP アドレスから別の要求がある場合
: 応答が数秒遅れる場合があります (並列スレッドを待っているため、その間に偽の CSS がダウンロードされる可能性があります... )、グレーリスト データベースを定期的にチェックして、IP アドレスが消失したかどうかを確認します
。b) 1 ～ 2 秒の時間枠: 単純に応答を拒否し
ます。
しかし、これはまだ完全ではありません。このメカニズムの間、潜在的なボットに 1 つの実際のページを提供したため、これを回避することもできると思います。この最初のリクエストに対して、わずかに遅れて空のリダイレクト ページが返される場合があります。これは、HTML HEAD セクションで簡単に実行できます。または、そのために Javascript を使用することもできます。これは、やはり優れたボット フィルターです...ただし、Javascript をオフにすると、実際のユーザー フィルターにもなる可能性があります (ユーザー エージェント文字列がなく、スイッチが入っていない訪問者がいる場合は、そう言わざるを得ません)もちろん、ページに「すぐにリダイレクトされます」などのテキストを追加して、潜在的な実際のユーザーを落ち着かせることもできます。このページがリダイレクトの発生を待っている間に、本物のブラウザが偽の CSS をダウンロードします。そのため、リダイレクトが発生するまでの間、IP がホワイトリストに登録されます。