セッション複数端末ログイン、共有方法は？

たとえば、Baidu アカウントにログインすると、Tieba に入ると、すでにログインしていることがわかりました。Nuomi に入ると、自動的にログインしていることがわかりました。

別の例として、淘宝網にログインし、Alipay を開いたところ、Alipay もログインしていることがわかり、Tmall に入ると Tmall もログインしていることがわかり、Tmall を終了すると、淘宝網もログアウトしていることがわかりました (ただし、Alipay はログアウトしていません)影響があるようです)

Meituan にもログインし、Meituan Takeout に入ると、ログインしていることがわかります。どうすればよいですか?

NetEase Pass、Baidu Pass、およびアプリケーション間でのログイン セッションなど、アカウントは共有できるように感じますか? PHPSESSION の Cookie はクロスドメインであっても共有できます。統一ドメイン名は問題ありませんが、nuomi.com はどうですか? はい、それは本当に邪悪です。

Discuz には過去に UCenter ホームがあったことを覚えていますが、それは単にこの目的のためでしたか?

このナレッジポイントは何と呼ばれますか?複数ログイン?セッション共有?

具体的にはどうすればよいですか? この場合、ファイル内に SESSION が存在しないはずです。redis、memcached などを使用すると、どのような問題が発生しますか? 、QQセキュリティセンターのような？

現在、私のプロジェクトではセッションを保存するためにファイルを使用しています。これはパス モードと同等ですが、異なるアプリケーションはログイン時に異なるセッション プレフィックスを使用するため、個別にログインするたびに、このサーバーではセッションの切断が頻繁に発生し、ユーザーのログイン状態を監視する方法がなく、不愉快な思いをしています。

マスターからの指導と重要な知識ポイントを教えてください。それから情報を探してもいいですか？

返信内容:

たとえば、Baidu アカウントにログインすると、Tieba に入ると、すでにログインしていることがわかりました。Nuomi に入ると、自動的にログインしていることがわかりました。

別の例として、淘宝網にログインし、Alipay を開いたところ、Alipay もログインしていることがわかり、Tmall に入ると Tmall もログインしていることがわかり、Tmall を終了すると、淘宝網もログアウトしていることがわかりました (ただし、Alipay はログアウトしていません)影響があるようです)

Meituan にもログインし、Meituan Takeout に入ると、ログインしていることがわかります。どうすればよいですか?

NetEase Pass、Baidu Pass、およびアプリケーション間でのログイン セッションなど、アカウントは共有できるように感じますか? PHPSESSION の Cookie はクロスドメインであっても共有できます。統一ドメイン名は問題ありませんが、nuomi.com はどうですか? はい、それは本当に邪悪です。

Discuz には過去に UCenter ホームがあったことを覚えていますが、それは単にこの目的のためでしたか?

このナレッジポイントは何と呼ばれますか?複数ログイン?セッション共有?

具体的にはどうすればよいですか? この場合、ファイル内に SESSION が存在しないはずです。redis、memcached などを使用すると、どのような問題が発生しますか? 、QQセキュリティセンターのような？

現在、私のプロジェクトではセッションを保存するためにファイルを使用しています。これはパス モードと同等ですが、異なるアプリケーションはログイン時に異なるセッション プレフィックスを使用するため、個別にログインするたびに、このサーバーでは、セッションの損失が頻繁に発生し、不可解な自動ログアウトが発生し、ユーザーのログイン状態を監視する方法がないため、気分が悪くなっています。

マスターからの指導と重要な知識ポイントを教えてください。それから情報を探してもいいですか？

まず第一に、新しいテクノロジーを恐れたり、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は当たり前になります。

ご不明な点がございましたら、コメント欄に直接ご質問ください。すぐにお答えいたします。

同じドメイン名であれば、実際に COOKIE を設定できます。異なるドメイン名であれば、上記の SSO であり、これはセッションを共有するものではなく、ログイン状態を共有するだけです。 。負荷分散のみがセッションを共有できます

1. 概要

セッション複数端末ログインはセッションの整合性を保つためのものです。セッションは一意であるため、セッションの一意性を維持するには、全員がセッションを取得するときにセッションを 1 か所に保存し、セッションの一貫性を維持します。
2. セッション
を実装する方法は、実際にはセッションを 1 か所に保存し、誰もがそれにアクセスできるようにすることです。その他については、すべて追加であり、原則は姜子です。一般的な実装方法は次のとおりです:
1) nfs ファイル共有システム。異なるプロジェクトが同じ共有ファイルにアクセスできるようにします。
2) mysql に保存されます。
3) Redis、memcache などのメモリ内データベースに保存されます。
4) Cookie ベースの共有。これには、統一されたドメイン名が必要です。
3. Redisのセッション共有に関しては他も同様です
1) php.iniにセッション保存アドレスが存在します セッションアドレスをredisがセッションを保存するアドレスに変更できます。 session.save_path
しかし、通常、この種のサーバーにはアクセス制御があります。したがって、2 番目の方法を参照してください
2) セッションを書き換え、PHP コードを通じてセッションのストレージ パスを変更します。 PHP には、関連するセッションが書き換えられたクラスがあります。

ご招待ありがとうございます

シングル サインイン SSO を使用すると、複数のサブサイト Web サイトとメイン サイトで同じログイン システムを使用できます。たとえば、CSDN Webmaster China はこれを行っています
ログイン情報とトークンを Redis に保存するだけです。 Redis のヒット率の問題を考慮する必要があります

それが SSO、シングル サインオンです

シングルサインインのオープンソースフレームワークを使用し、php、.net、javaをサポートします

シングルサインオンSSOについては、CASの関連情報を確認できます。
このブロガーの記事を読むことができます: http://denger.iteye.com/category/161641

シングルサインオンSSO