linux - PHP シングル サインオンにはどのソリューションが適していますか?

UCente は比較的既製ですが、私のプロジェクトとあまり互換性がありません。共有セッション サーバーを使用する場合はどのように設定すればよいですか? 誰か良いアドバイスと指示をいただけますか?

返信内容:

UCente は比較的既製ですが、私のプロジェクトとあまり互換性がありません。共有セッション サーバーを使用する場合はどのように設定すればよいですか? 誰か良いアドバイスと指示をいただけますか?

以前同じ質問に回答したので、再度取り出して回答させていただきます。
タイトルをお読みください

まず第一に、新しいテクノロジーを恐れたり、SSO (シングル サインオン) をチェックしたりしないように注意してください。実際、これは問題の複雑さを増大させ、この問題に対する恐怖心を増大させるだけです。それは本当にそれほど難しいことではありません。

---

あなたが言及したセッションのマルチターミナルログインは、実際には、必要なセッション値にすぎません。 Access では、異なるドメイン名の異なるサーバーで、誰もが同じ Session 値を読み取ることができます。重要なのは、同じ session_id() 値です。この場合、各 (サーバー/プロジェクト) は同じデータ (特に同じ session_id() 値) を読み取るため、この識別子を使用して、異なるユーザーに異なるコンテンツを表示させることができます。多重ログインが解決されました

(問題を単純化するために、ログインはユーザーにとって特別なプロセスです。私たち開発者の観点から見ると、それは異なる人が異なるデータを読み取ることができるようにするだけであり、必要なのはログイン識別子を取得することだけです。)

言い換えれば、セッション共有の重要な技術的ポイントは次の 2 つの点にあります。

1. クライアントが同じセッション ID にアクセスできるようにします。
2. すべてのドメイン名に対応するサーバーがアクセスするセッション データの場所は一貫している必要があります。 以下では実装に焦点を当てます。セッション共有は 4 つの状況が比較的多いため、Cookie 共有よりも複雑です。 同じサーバーは同じドメイン名を持ち、同じサーバーは異なるドメイン名を持ち、異なるサーバーは同じドメイン名を持ち、異なるサーバーは異なるドメイン名を持ちます。

同じサーバーと同じドメイン名の実装 (異なるサブドメイン名):

実装は比較的簡単です。オンライン デモ (画像の侵入と削除) を見つけて、次のコードに従って実装します。

同じサーバー上での異なるドメイン名の実装:

この場合、

同じセッションID

、同じデータソースという、セッション共有を実現するための主要な技術的ポイントを再度明確にします。 異なるドメイン名がある場合は、まず Cookie (「PHPSESSID」) をクロスドメイン化し、次にこの sessionid 値を使用して MySQL データベースまたは Nosql から対応するデータを取得する必要があります。これにより、異なるドメイン名でのセッション共有が実現されます。同じサーバー。 最初は Cookie クロスドメインです:

次に、Redis データ共有があります。キーは session_id で、値は Redis クラスター テクノロジーが使用されています。興味がある場合は、記事に直接アクセスしてください。表示: Redis クラスター クラスターのインストール構成の詳細な説明

異なるサーバー上での同じドメイン名の実装:

この状況は

<同じサーバー上に異なるドメイン名を実装>

に似ていますが、この場合はクロスドメイン Cookie の問題を考慮する必要がないため、上記と同じようにデータ共有だけに集中してください。 、キーは sessio_id 、値は 特定のデータ値については、Redis クラスターのクラスターのインストールと構成の詳細な説明について上記の記事を参照してください。

異なるサーバー名と異なるドメイン名の実装:

この状況と、

<同じサーバー上での異なるドメイン名の実装>

画像アクセスも、

同じセッションIDと同じデータソースという2つの目標を達成する必要があります。ドメイン名が異なる場合は、最初に Cookie (「PHPSESSID」) をクロスドメインにし、次にこの sessionid 値を使用して MySQL データベースまたは Nosql から対応するデータを取得する必要があります。これにより、同じドメイン上で異なるドメイン名とのセッション共有が実現します。サーバ。 最初は Cookie クロスドメインです:
次に、Redis データ共有があります。キーは session_id で、値は共有する必要があるデータです。この例は非常に複雑です。興味がある場合は、記事を参照してください。表示するには: Redis クラスター クラスターのインストールと構成の詳細な説明。

4 つのケースの解決策は似ていることがわかりました。2 番目のケースと 4 番目のケースは、基本的に次のとおりです。同じですが、中心となるアイデアは、全員が同じ session_id を取得する必要があり、全員が取得する必要がある共有データ ソースが存在するという 2 つの根本的な問題を解決することです。

この2点を理解すれば、Sessionで共有するSSOは当たり前になります。
ご不明な点がございましたら、コメント欄に直接ご質問ください。すぐにお答えいたします。

ucenter を使用できない場合は、使用しないでください。 。 。ただ痛いです

SSO に加えて、ユーザーデータの統合の問題もあります。
この問題を解決するために、私は複数のサイトとタイプをサポートするウェブサイト構築プログラムを単純に開発しました。

Cookieを使用して各ユーザーの情報を個別に保存します