昨日、もちろん、状況について学ぶことは驚きでした。 最初にしたことは、すべての店舗がこのような問題を起こしやすいかどうかを確認することでした。 すべてではないことが判明しました。 ある種のプラグインまたはサードパーティのサーバーモジュールをインストールした店舗に問題がある可能性があるというプレゼンテーションがありました。 しかし、これは事実ではないことが判明しました。 Yandexの検索結果に表示される個人顧客データを含むページを持つすべてのストアは、 インストール済みのYandex.Metricaコードという1つのものによって統一されました。 まさに、メガフォンの最近のケースのように。
次に-プライベートページへのリンクがどこから来たのか、Yandexインデックスにどのようにアクセスできるのか、問題の大きさ、可能な解決策について。
問題はこれでした：
- Shop-Scriptベースのオンラインストアでは、登録せずに注文できます。 つまり、ユーザー名とパスワードを入力せずに。
- 注文が行われた後、購入者には注文の電子メール通知が送信されます。この通知には、注文に関する詳細情報、ステータス、注文の支払い能力、および処理の履歴を表示するページへの直接リンクがあります。 登録されていないユーザーによって注文が行われるため、このページは通知レターからのリンクによって開かれます（リンクでは、当然、GET要求ですべてのパラメーターが送信されるハッシュを介して認証が行われます）。 このコンテキストにはパスワードがないため、ユーザーからパスワードは要求されません。 オンラインストアで注文するために必須の登録が必要です。ご承知のとおり、買い手にとっては完全に不便であり、注文の履歴を含むページを表示する必要があります。
- Yandexはそのようなページだけにインデックスを付けました。 より正確には、バイヤーが訪問したページ（通知レターのリンクをたどる）。
- Googleや他の検索エンジンは、それに関する情報がHabréのニュースフィードに登場し、「一般の知識」になった後、同じページをインデックスに登録しました。
次の運用上の決定を行いました。姓によるユーザー認証を固定しました。 ユーザーが注文通知書のリンクをクリックした場合、まず名前を尋ね、正しく入力した場合にのみ、注文に関する情報を表示します。 もちろん、これはあまり美しい解決策ではないと言うこともできますが、この場合は「信頼できる」唯一のパラメーターです。 さらに、すべての「問題のある」GETパラメーターをYandex.Metricaに渡さずに一度に「食べる」リダイレクトを追加しました（これについては後の記事で説明します）。 パッチと更新されたバージョンは、当社のWebサイトのブログで公開されています。
今から楽しい部分です。 Yandexは、ユーザーに個人的にのみメールで送信されたアドレス（URL）をどのようにして見つけることができますか？ 影響を受けるすべてのオンラインストアは、インストールされたYandex.Metricaコードという1つの共通の機能によって統合されているため、Yandex.Metricaが修正するアドレスは、一般的なYandexインデックスになったと結論付けるのは簡単です。 これらのアドレスは、Shop-Scriptオンラインストアの側で公開されたことはないため、アドレスが公開ソースにあると言うのは誤りです。 Yandexが新しいページを見つける方法について5つのポイントでYandexの回答を読みましたが、この質問に対する答えは見つかりませんでした。 もちろん、アドレスがどのように「マージ」されたかは明らかです。もちろん、今後はこれを考慮します。 （ところで、建設性と良い例については、Yandex Webサイトのディスカッション「Why is everything」の最初のコメントの著者に感謝します。）
状況の規模は、認証パラメーターをGETパラメーターとしてレターまたはいずれの場合でも送信する方法が非常に広く使用されているという事実にあります。 これは、Megafonおよび当社の場合と同様のケースが、他のサイト、エンジン、およびサービスで将来発生する可能性があることを意味します。 これは明らかであり、時間の問題です。 「メガホン」のケースは、この問題に大きな注目を集めました。
たとえば、番号を送信することにより、少なくともオンラインパッケージ追跡の一般的なサービスを利用してください。 荷物の送信者はサイトに登録されておらず、たとえば電子メールでトレースページでアドレスを受信するだけです。 住所をお気に入りに追加して、ステータスを定期的に確認することができます（たとえば、私はいつもこれを行います）。それを荷物の受取人に送信できます。 同時に、このようなアイテムのオンライントレースシステムは、ユーザーが認証データを入力する必要がないため、アプリオリに構築されたとは言えません。この場合、ユーザー名とパスワードはありません。 送信者にロシアの郵便でのアカウントの受信を強制しないでください。
ユーザーが（自動認証を使用して）アカウントに直接つながる電子メールリンクを受信したときの通知の例は、インターネット上に豊富にあります。 私の知る限り、YandexのMy Circleサービスはこのようなシステムを使用してユーザーを認証します。
それでは解決策について話しましょう。
Megaphoneの場合のように、開発者の主な省略は、誤って形成された（または欠落した）ファイルrobots.txtと呼ばれていました。 この場合、ファイルに正しい指示が存在することは問題の防止に役立つことに同意しますが、robots.txtは規範的な性質ではなく推奨事項にすぎないため、一般的な意味ではこれは完全な解決策ではありません。 robots.txtが今日の検索ボットを考慮するのは良いことですが、今後これがどのように処理されるかは未解決の問題です。 突然ボット内の何かが壊れます。 または、ボットは検索されません...
これに関して、すべてのプライベートページを表示するために必須のユーザー認証を導入することによってのみ、問題を完全に（最も一般的な場合）解決できます。 これが受け入れられず、ユーザーが明示的に指定されたGETパラメーターを使用してリンクをクリックした直後にいくつかの個人情報をすぐに表示する必要がある場合（アイテムのトレースの例のように）、リンクをクリックした直後にPHPをページにリダイレクトすることは技術的に合理的ですこれらのパラメーターなしで、セッションでそれらを記憶します。 これにより、ページにインストールされているJSカウンター（Yandex.Metric、Googleアナリティクスなど）にパラメーターを持ち込まないようにできます。開発者はこれに注意を払い、プロジェクトでそのようなリダイレクトを行うことをお勧めします。 ただし、これは部分的な解決策でもあります。これは、インストールされたバーまたはブラウザのプラグインによってリダイレクト前に突然アドレスが認識されるためです。 まあ、または間接的なパラメータによる追加の承認を導入します（姓チェックで行われたように）...
私は一切請求しませんが、Yandexは一般的な検索インデックスに新しいアドレスを追加する方法を再検討し、このアドレスがどれほど巧妙に修正されても、ユーザーが訪問したアドレスを公開アドレスに変える慣行を廃止すべきだと思います。 この習慣は少なくとも非倫理的です。 そして、問題が大規模になるまで、できるだけ早くそれを改善する。
他人の過ちから学び、時間通りにそれをしようとする。 ご清聴ありがとうございました。
UPD：問題は勢いを増しているようです。 さて、ここに列車のチケットがあります： http ： //news.yandex.ru/yandsearch？cl4url = www.ria.ru％2Fsociety％2F20110725％2F407118103.html