パスワードなしでサイトに入ることについての思考記事

ユーザーがGoogle / Twitter / Facebookなどを介してログインできるようにする必要性に関する記事がHabréで1回または2回以上公開されています。 実際のところ、進歩的な人類は、ユーザーにユーザー名とパスワードを求めることは昨日だと長い間決めてきました。 この記事では、新しい問題とその解決方法について説明します。

簡単な紹介

現時点では、私は、 Kohana phpフレームワークのコミュニティのソーシャルネットワークの要素を使用して、一種の情報ポータルと参照ポータルを作成することを決定した愛好家チームの開発者の1人です。 コメント/レビューを書いたり、投票や評価に参加したりするには、認証が必要です。 OpenID / OAuthを使用して入力を固定するのは簡単です。考え始めると興味深いものが表示されます。次は何ですか？



原則として、理論的研究に焦点を当てることを事前に警告する価値があります。 説明したメカニズムの準備ができ次第、これは恥ずかしいことではありませんが、すぐに示します。

認証

データベース

サンプルデータベーステーブルの概要を説明します。これにより、ユーザーから取得できる情報の最大量を保存できます。



ユーザー



ここではすべてが明確です。これはユーザーを保存するためのメインテーブルです。

• id
  
  
  
  ユーザーid
  
  
  
  自動インクリメント。 他のサイトオブジェクトとの通信にこの識別子を使用する予定です。
• username
  
  
  
  -サイトに表示される表示名。 最初に、OpenIDまたはOAuthデータに基づいて生成しますが、変更する機会を確実に与える必要があります。
• email
  
  
  
  -メールアドレス。 最初は、使用されている外部アカウントから引き出しようとしています。 これは常に可能とは限らないため、フィールドはオプションです。

auth_data



このテーブルは、外部ユーザーアカウントを操作するためのものです。 たとえば、ユーザーAがGoogleとTwitterに1つのアカウントを持っている場合、1つのユーザーエントリのauth_dataに2つを提供する必要があります。

• id
  
  
  
  一般に、すべてが明確です。 合成自動インクリメントキー。
• service_name
  
  
  
  は、ログインに使用されるプロバイダーの名前です。 認証メカニズムとサービスの実際の名前で構成する必要があります。 たとえば、livejournalアカウントでOpenIDを介してログインした場合、「openid.livejournal」を取得し、「oauth2.github」はgithubアカウントを意味し、OAuth v2からアクセスできます。
• service_id
  
  
  
  上記のサービスのユーザーアカウント識別子。 つまり ログインします。 service_name
  
  
  
  とservice_name
  
  
  
  一意のインデックスを取得します。サイトにはそのようなユーザーがこれ以上いないはずです。
• email
  
  
  
  -再び石鹸！ そのユーザーを変更することはできません。また、重複したユーザーを検索したり、人間のログインを生成したりするなど、 汚い目的で使用することもできます。
• some_data
  
  
  
  ここでは、プロバイダーから受信した他のすべて（シリアル化された形式）をsome_data
  
  
  
  します。 便利になったらどうしますか？ もちろん、フィールドは捨てることができます、それはth約家であり、元気な所有者のスコピドムのためです;）

コミュニケーションズ



当然、アカウントは特定のユーザーにリンクする必要があるため、 user_id外部キーがauth_dataテーブルに表示されます。



奇妙なことに、ユーザーをアカウントにバインドするために、 ユーザーテーブルにauth_id



外部キーも追加します。 なんで？ したがって、特定のプライマリアカウントを強調表示します。 たとえば、一部のデータを自動的にユーザープロファイルに転送したり、自動ログインを実装したりします。 決定は議論の余地があるように見えるかもしれませんが、現時点では合理的かつ有用であると考えています。

悪魔、入れてくれ！

そして今-認証メカニズム自体。 手順。

1. 「Enter through」ボタンをクリックするか、OpenIDを入力するか、単にプロバイダーの写真をクリックしました。 あなたがあなたであることをプロバイダーに確認/証明しました。
2. プロバイダーからサイトに返送された後、データベースでこのユーザーの可用性を確認する必要があります。 すでに入っている場合はどうしますか？ これを行うには、上記の組み合わせservice_id
   
   
   
   + service_name
   
   
   
   使用しservice_name
   
   
   
   。 アカウントが見つかった場合、すべてが簡単ですuser_id
   
   
   
   でユーザーを抽出し、実行しuser_id
   
   
   
   。
3. ただし、以前はアカウントがサイトの範囲に含まれていなかったため、気が変わる前にすばやく登録してみましょう。
   
   
   
   auth_dataには 、プロバイダーが提供したすべてを入力します。 このデータに基づいて、 username
   
   
   
   を生成しようとしusername
   
   
   
   ます。 新しいユーザーを保存し、 プライマリとして使用するアカウントを指定します。 ほら、新しいユーザーがいます！

さて、議論するものは何ですか？

ルーチンについて簡単に説明したので、プログラマーの追加の努力が必要なさまざまなケースを見てみましょう。

私を覚えて！

多くの場合、以前にどのアカウントでサイトにアクセスしたかを覚えるのが難しくなります。 そして、なぜ、彼はそれをもっと必要としているのかを覚えておいてください。 したがって、ログインに成功した後、ユーザーが次回自動的にログインできるように、トークン付きのCookieをスローします。



これは安全ではない、とあなたは言い、あなたはおそらく正しいでしょう。 したがって、トークンを生成するときに、クライアントに関するさまざまな情報（IP、ユーザーエージェントなど-選択肢があります）も保存します。 ユーザーが（「exit」ボタンを使用して）明示的にサイトを離れると、Cookieが削除されます。 さて、自動ログインでは、ユーザーが重要なデータを変更する（石鹸またはログインを変更する）場合に確認が必要になります。 極端な場合は、「私を覚えていない」チェックボックスを描画できます。



当然、OAuthの場合、APIサービスを使用するには（アカウントにツイートを送信するなど）作業トークンが必要です。そのため、「記憶」をまったく使用しないか、適切なタイミングでプロバイダーに送信して確認する必要があります。

覚えてる？ いや？ 覚えて！

ユーザーがログアウトしてアルバニアに長期間移住しなかった場合でも、認証を手伝う必要があります。 ユーザーがログインした瞬間に戻りましょう。 上記で、特別なCookieについて書きました。 彼女の1つでは十分ではないことがわかりました-2つ目を投げます。 長い期間。 内部には、入力したアカウントの識別子が保存されます。



戻ってきた。 そして、この長期にわたるクッキーは私たちを助けます。 それに基づいて、「Googleを使いました、バディ！」などのメッセージをユーザーに表示します。 当然、別のアカウントを希望する場合は、Cookieを新しいアカウントに変更します。 結局、私たちはただのサイトであり、気にしません。

別のアカウントからサインインする

ええ、別のアカウントで、あなたは言います！ では、ユーザーを複製しますか？ 結構です。 私たちはこれと戦わなければならず、そうするためにあらゆる努力をします。



まず、Cookieの寿命を確認します。 彼女はすべてがきれいではないこと、そして潜在的に私たちが2番目のアカウントを作成していることを教えてください。 したがって、これが別のアカウントであるか、まだ存在するかをユーザーに尋ねます。 別の場合は、Cookieやその他の情報を事前にクリーニングした後、マイレージがゼロの新しいレコードを作成します。



しかし、ユーザーがこれがまだ彼であると主張する場合、何らかの理由で私たちのために異常な方法で入力したい（私たちはこれを覚えているauth_dataにすべてのものがあります）、あなたはチェックをする必要があります。 オフハンドには、いくつかのオプションがあります-元のアカウントでログインすることを提案する（つまり、 プライマリで -これを指定するもう1つの理由です）、またはメールに確認コードを送信します（ユーザープロファイルで指定されている場合）。 正式には、 primaryの下にエントリを必要としない場合があります。すでに確認されているものはどれでも十分です-ご希望のとおり。



ユーザーが自分の権利を確認できなかった場合、新しく作成されたアカウントを削除します。嘘をつくことはありません。

メールを見てください！

実際、メールアドレスはユーザー識別子として安全に使用できます。 したがって、Cookieが見つからなくても、プロバイダーが使い慣れたemail



を返した場合でも、パス（アカウントのマージまたは新しいパス）を選択して同じダイアログを提供します。 ああ、それはすべてのアカウントが石鹸を与えるわけではないのは残念です...

あなたの手の中の旗！

ユーザーがアカウントを混同するまで待つのはなぜですか？ 彼がまだベビーベッドを持っていることを彼に指摘させてください。 プロファイルには（ プライマリアカウントの下のみ？）「自分のアカウント」と見なせるアカウントを追加する機能があります。 そして、あなたは奇妙な質問で人を困らせる必要はありません。

Githubについて

Github が OAuth v2をサポートしていることをご存知ですか？ そして、彼はそうすることができます。 私たちのプロジェクトにとって、このサービスは特別です、あなたは最愛の人と言うことができます。 ユーザーがGithub経由でログインするとすぐに、追加のなめをすぐに開始します。

1. これについては話しませんでしたが、 usersテーブルにはdeveloper_id
   
   
   
   フィールドも格納developer_id
   
   
   
   ます。 これは、 developersテーブル（こんにちは、Cap！）にリンクするための鍵です。ここには、APIを通じてGithubから渡された開発者が格納されています。 実際、 Kohana用に開発されたモジュール（これはプロジェクトの主なタスクの1つです）を収集するため、訪問者の1人がいくつかのモジュールの作成者であることを知ることは非常に便利です。
2. ユーザーから追加情報を収集する必要はありません。 また、ユーザーがプログラマーである場合、この情報はさらに役立ちます（khe-khe）。 登録が成功した後、Githubberに彼の著者のN個のモジュールがあることを思い出させます。彼はいくつかのデータ（互換性、バージョン、説明など）を編集できます。 いやいや 自分で処理できます。 それでも、開発者に著者の新しいモジュールの追加に関する通知をメールで送信します（通知をオフにするオプションも実行します）。

私は何について話しているのですか？

当然、多くの落とし穴があります。 私は、サイト訪問者の側から、説明されたアルゴリズムと起こり得る間違い/省略について事前に議論したいと思います（このスキームはどれほど便利ですか、提案がありますか、またはそのようなサイトでは常に何かがあなたを悩ませていますか？）、そして開発者の観点から横枠があるかもしれません）。 実際、Habréに関する記事へのコメントには、記事自体よりもはるかに有用な情報が含まれていることがよくあります。