PHPセッションのクロスドメインおよびクロスサーバーのソリューションの共有

asp.net を除き、すべてのセッション予約にはセッション ID を使用する必要があります。 セッションの保存場所には主に、共有ファイル、データベース、memcache が含まれます。

セッション ID を渡すには主に 4 つの方法があります。 1. Cookie を介して。 2. php.ini で session.use_trans_sid = 1 を設定するか、コンパイル時に --enable-trans-sid オプションをオンにして、PHP がページ間でセッション ID を自動的に渡すようにします。 3. URL または非表示フォームを介して値を手動で渡します。 4. ファイルまたはデータベースを介してそれを渡し、他のキーを介して対応する値を取得します。 上記2と3は実は同じ方法ですが、方法が異なります。 上記の分析から、Cookie を介してセッション ID を渡し、セッションを memcache サーバーに保存する方がより合理的な選択であることがわかります。 クロスドメインの状況が発生した場合、p3p を使用してドメイン間で Cookie を設定できます。 クライアントが Cookie を無効にすると、URL を通じてセッション ID を自動的に渡すように php.ini を設定できます。

論理実装プロセスを説明するためにパスを例に挙げます (要件に応じて異なります。インターフェイスの一貫性を確保し、セッション サーバーを他のサーバーから保護したい場合は、すべてのログイン情報とセッション情報をログイン サーバー経由で転送できます)ただし、これにより当然時間の遅延が発生し、ログイン サーバーのダウンによってサイト全体が麻痺するリスクが発生します。 サービスとアプリケーションが含まれます: ログイン サーバー、セッションを保存するための memcache サーバー、アプリケーション サーバー、公開キー、秘密キー 1) 信頼できるサーバーの場合: ユーザーが送信したユーザー名、パスワード、およびその他の情報は、ログイン公開キーで暗号化して、クライアントからログイン サーバーに直接送信することも、ユーザー ログインの RPC 呼び出しを通じてログイン サーバーに送信することもできます。

ログインサーバーは、ログインユーザーの関連情報を取得し、セッションの形式でセッションサーバーに保存し、p3pメソッドのクライアントCookie内のすべてのドメイン名にセッションIDを設定します。セッション暗号化公開キーで暗号化されます。 rpc 呼び出しが使用される場合、クライアント Cookie はサーバーによって設定されます。すべてのドメイン名が設定されていない場合、設定されていないドメイン名の下にあるモジュールを個別に再度ログインする必要がある場合があります。 (Cookie が使用できない場合、URL はセッション暗号化公開キーを使用して暗号化されたセッション ID を渡すために使用され、クロスドメインの問題は発生しません。)

ログイン後、クライアントはセッションを通じて公開キーを復号化し、Cookie または URL を通じて渡されたセッション ID を復号化し、この ID を通じてセッション サーバーから対応するセッション情報を取得し、モジュール間をローミングします。 (ログインサーバーを介してセッション情報を統一的に読み取ることもできます。セッションサーバーは複数マシンのスケジュールされたバックアップを使用して、ダウンタイムやサービスの再起動によるユーザーのログインセッションの損失を防ぐことができます。)

2) 信頼されていない協力ユーザーの場合: ユーザー名、パスワード、または検証コードなどの関連パラメータは、API インターフェイスを介して渡すことができます。認証コードは、双方が確認した特定のキー、またはユーザー情報やその他の情報です。 サーバーにログインしてソースを確認すると、ワンタイム使用キーが生成され、呼び出し側に返されます。 キーは要求側とログイン サーバーによって共同で保存および維持され、保存および維持が必要なその他の関連情報は要求側によって完了されます。 次の実装と (1) の主な違いは次のとおりです。 1) 最初に要求者の身元を確認する必要があります。 2).公開キーの代わりにキーを使用します。 3). セッションを読み取るには、サーバーにログインする必要があります。

上記の説明が皆さんにインスピレーションを与え、クロスドメインおよびクロスサーバーセッションの問題の解決に役立つことを願っています。