それでは、タスクに戻ります。
単一の承認が必要な元のプロジェクト（project1、project2、projectN ...）がいくつかあります。 つまり、プロジェクトproject1にログインしているユーザーは、承認されたユーザーとしてproject2 ... projectNのリソースにアクセスできました。
原則として、そのようなプロジェクトは単一のホスティングにあり、共通の（単一の）登録を持っていることが望ましいです。 そのため、これらの条件が満たされている場合、以下に説明するソリューションはプロジェクトを継続できます。
制限 ：すべてのプロジェクトは同じデータセンターにあり、同じローカルネットワーク上にあります。 すべてのプロジェクトには、セッション用の単一のリポジトリがあり、それに応じて単一のsidがあります。
私たちは次のことに同意します：
- project.comはプロジェクトの1つです。
- sso.comは一般的な承認サーバーです。
ロギング
- project1.comのユーザーが[ログイン]リンクをクリックします。
***または、url sso.com/signin/project1/#sidに投稿することもできます
#sidはセッション番号です
- sso.com/signin/project1/#sidにリダイレクトしています
- サイトproject1の設計が表示され、プロジェクトの設計はクエリ行によって計算されます
***投稿があった場合、プロジェクトのデザインを表示してすぐに承認に進む必要はありません - ユーザーがユーザー名とパスワードを入力します
***投稿があった場合、アイテムは必要ありません - 認証が成功した場合、シリアル化された（JSON形式の）オブジェクトUserがmemkeshに書き込まれ、
キーは#sidです
次はproject.com/welcome/#sidへのリダイレクトです - セッション番号なしでproject.com/welcomeにリダイレクトします（#sid）
- 認証が成功しなかった場合、progect1.com / error / 401（認証なし）にリダイレクトします。
ログイン
- project1.com Webサイトのユーザーは、承認が必要なセクションに含まれています。
- キーは、memcacheのサーバーでチェックされます。キーはセッション番号です。
- キーが存在するため、プロファイル（ユーザーオブジェクト）から必要なデータをすべて引き出して先に進みます
- キーが存在しない、認証サーバーのログインフォームへのリダイレクトsso.com/signin/project1/#sid
別のプロジェクトからの承認
- project1.com Webサイトのユーザーは、承認が必要なセクションに含まれています。
- sso.comはmemkeshキーsid Userオブジェクトに入れます
- ユーザーはproject2.com/signin/#sidにアクセスします
- project2.comでは、＃sidキーが存在するかどうかが確認され、サイトのすべてのセクションにアクセスできます。
出口
memkeshでキーを殺すか、彼が死ぬ
余計な質問ではない
しかし、「見知らぬ人」があなたのsidを使用してproject1.com/signin/#sidにログインすることを決定した場合はどうなりますか
はい、可能です...通常のsidが保存されているcookieを傍受するのと同じ確率で、urlのsidを傍受できます。
おわりに
統合登録システムは、ユーザーがsso.comに登録することを前提としています
sso.comのデータアクセスには、どのプロジェクトからでもアクセスできます。 承認との類推による登録中のすべての遷移、URLのみが異なります：sso.com/registration/project1（project1は、登録を表示するデザインと登録後にユーザーを返す場所を示します）
sso.comのデータは、キー/値データベース（BerkleyDBなど）に格納できます（必ずしもそうである必要はありません）。
PS。 ログインフォームに頻繁に表示されないようにするには、memekeshのパッチを使用する必要があります-自動延長（これについては別のトピックで）
このパッチは、最後のデータアクセス後に同時に自動延長を行います。