問題文
しばらく前、作業
たとえば、サイトにloginzaなどの美しいソケットがある場合や、連絡先、twitter、facebookなどの承認ウィジェットだけがある場合を考えてみましょう。 ログインは簡単？ もちろん。 しかし、同時に、ある人がこれらすべてのアカウントからすぐにログインした場合（同時にでもそうでなくても問題ではありません）、システムにとっては異なる人であり、したがって、おそらくそのアカウントがサイトにまったくない同じ人のクローンです。
違いは何ですか、サイトにアカウントを登録するか、外部リソースからログインしますか？
そして、それはすべて私たちのプロジェクトの本質に依存しています。 たとえば、ニュースを読んだり、コメントに
スターウォーリアーズ-クローンの攻撃
この記事は本質的に純粋に理論的なものであり、それを読むことに決めたすべての人々のアイデアや提案を聞くことを目的として作成されました。
問題の解決策を見つける
利用可能なリソースを一目見、最も一般的なサービスのAPIを調べると、それが判明しました（「わあ、気にしないで！しかし、私は知りませんでした！」の意味ではなく、「あー...ここに、ここに、そしてここでも、」）彼らはすべて同じ原則に基づいて動作します。
ユーザーはウィジェットを介して外部リソースにリクエストを送信し、一般に、このリソース上のユーザーの識別子、一部のアカウント情報、および開発者が利用できるアルゴリズムによって生成された秘密鍵を返します。 そして、同じ開発者がこのデータをサイトでどんな方法でも使用できます。
非常に漠然としたグーグルと結果の分析の後、原則として、サイトにログインしているユーザーの身元を明確に識別するタスク-リンク-を解決する方法が考案されました。
料理
以下のアルゴリズムを一般的な用語で説明しようとしますが、現在kohanaフレームワークを使用しているため、このフレームワークの観点からプロセスを誤って説明する可能性があるため、あまり誓わないでください。
したがって、まず最初に、データベースに3つのテーブルが必要です。
最初のテーブルは「 ユーザー 」と呼ばれ、奇妙なことに、それは私たちのウェブサイトに登録されているユーザーのリストを含みます。 構造は任意ですが、フィールドが必要です
-ユーザーID
-ログイン（またはログインとして機能する一意のその他のフィールド）
-パスワード（暗号化されているかどうか、 自分で決めてください ）
2番目の表には、連絡先、Twitterなど、 当社のWebサイトで許可されている外部リソースのリストが含まれます 。これは次のようになります。
-リソースID
-リソースの名前（たとえば、「Vkontakte」）
-リソースのマシン名（たとえば、「vkontakte」）
-リンク内のユーザーIDの場所（「vkontakte.ru/{ID}」など）
-このリソース上のアプリケーション（この場合はサイト）のキー（ID）
そして、 3番目のテーブル 、そしておそらく最も重要なテーブルは、「 リンク 」です。これには、当社のWebサイトのユーザーアカウントと外部リソースのアカウントの対応が含まれます。 次のようになります。
-通信ID（クラシック、ハァッ？）
-リソースID
-当サイトのユーザーID
-外部リソース上のユーザーのID（または識別子）
また、将来、当社のウェブサイトで提供される各リソースについて、このウィジェットまたはそのウィジェットが表示する対応するビュー（一部のポップアップウィンドウやその他の不思議）、および関数（クラス、ヘルパー）が必要になります、モジュールなど）で、対応するAPIキーを計算してチェックしますが、これについては後で詳しく説明します。
いくつかのアルゴリズム
だから今、アクション自体。 最も簡単なものから始めましょう！
従来のログイン/登録フォームと、外部リソース用のウィジェットを備えたソケットを表示するWebサイトがあるとします。
従来の方法でサイトにログイン/登録し、最終承認手順に合格すると、そのサイトに移動するか、すぐにパネルに移動して設定セクションが表示されます。 このセクションに入ると、たとえば「外部リソースのプロファイル」などのパネルが表示され、外部リソースのテーブルにフィールドが作成されます。
ユーザーがVkontakteフィールドを選択し、そこに識別子を入力するとします。 プロセスの開始方法-入力に集中できなくなったとき、ボタンを押したとき、またはUFOのおかげで-それは重要ではありませんが、結果は重要です。 対応するウィジェット（ポップアップウィンドウ、目的のスクリプトのajax-request、またはその他）に対応する承認手順を開始します。
ユーザーが既に外部リソースで許可されている場合、必要なデータが返されます。そうでない場合、ユーザーはログインする必要があり、待望のデータを受け取ります。 そして、ここから魔術が始まります。
リソースから返されるキーは、特にリモートリソースのユーザーIDを含むデータセットからのハッシュです。 まず、既に作成したキー名を使用して特定のリソースのキー生成手順を使用します（適切な手順を呼び出すためにマシン名が必要な理由です）。ユーザーがサイトで入力した識別子を使用してこのキーを作成します。 次に、リソースから取得したキーを私たちのものと比較します。
2つのキーが一致し、入力された識別子がオープンで受信した識別子と一致する場合、指定されたアカウントの所有者が実際にいることを意味します。 この場合、「 Relationships 」テーブルに行を作成し、入力した識別子は一意になり、他の誰も同じ識別子を入力できません（オプションとして、入力しようとした場合、このIDの下に誰かが既に存在するというエラーを表示してこの人へのリンク）。
キーが一致しなかった場合、誰かの識別子を盗もうとしたり、アカウントでログインしたり、習慣からガールフレンド/ボーイフレンドのページにクロールしたかどうかを丁寧に尋ねたりするために人をscる価値があります。
上記は、ユーザーが指定したい識別子を持つすべての外部リソースに当てはまります。
最も簡単なオプションが実行されます。 私たちは最も難しいことに移ります-サイトに登録せずにシステムを介した承認。
この場合、この方法では、物理的なアカウントを作成する必要はありません。 たとえば、同じ連絡先からサイトにログインすると、セッションが開始され、大きなタブレットで次のような明るい警告が表示されます。
このアカウント％リソース名％は 、サイトに登録されているどのアカウントにも関連付けられていません。 今すぐアカウントにリンクするか、 新しいアカウントを登録できます 。
実際、すべてがこのウィンドウの問題に限定されるわけではありません。ユーザーが自分自身をアカウントにアタッチするように動機づけるために、たとえばコンテンツのみを見ることができるように、ユーザーの権利も切り捨てるからです。 まあ、またはそのような何か。 もちろん、ユーザーが警告のリンクの1つをクリックすると、ログインパスワードを入力することができ、登録の場合のように、現在サイトにログインしているIDがアカウントに自動的にリンクされます。
結論
たとえば、サイトに実際のアカウントがないユーザーを厳密に制限しますか？ 同意します。
しかし、簡単な登録手順を実行した後、彼はさまざまなリソースを介してワンクリックでログインできるようになり、常にサイト上のアカウントにアクセスします。また、既存のアカウントからのリンクプロセスには通常少し時間がかかります。 いずれにせよ、バインディングについての警告でさえwebdanolの最高の伝統で実装できるため、特に目を引くことはありませんが、同時に示唆されています。
残念ながら、現時点では上記のアルゴリズムを実装する時間はありませんが、実装する場合、まずはKohanaフレームワークの下で、したがって、今、私は建設的な批判とここでどのように改善できるかについての提案を聞いてうれしいです。 ご清聴ありがとうございました。