[php]異なるプログラムでのセッションの共有を実現したい

初めて投稿します。よろしくお願いします。

PHP にて、異なるプログラムでのセッションの共有について、何か良い方法が無いか模索しています。

現在、ワードプレスという「ブログ」と、ZENCART という「ショッピング」のシステムの間で、同じセッション情報が共有できないか試しています。

ワードプレスには、welcart という「ショッピング」のプラグインがあるのですが、それだと望むことが出来ないので、ZENCART という「ショッピング」のシステムと何とか併合したいのです。

ワードプレスでセッションを有効にするには、「wp-config.php」に、以下のコードを追加するだけで行けました。
if (!session_id()) {
session_start();
}
これで、ワードプレス内では、セッション情報が保たれていることを確認済みです。

一方、これでショッピングのシステムを開くと、ショッピングのシステムではショッピングのシステム間でのみのセッションがはられる（セッションIDが新規に作られる）ため、ワードプレスでのセッション情報が参照できません。

試しに、ショッピングのシステムの同一フォルダ階層にて、セッション情報だけを見るプログラムを走らせたところ、そこではセッション情報が見れています。

すなわち、２つのセッションがはられてしまっている訳です。

このような場合、みなさまどうされているのか、どのような方法が良いのか、他のショッピンサイトとの併合の場合の対処でも良いので、シェアして頂けると幸いです。

・やりたいこと
ワードプレスにおいて、ゲストとカスタマーで違う情報を見せたい。
→これは、ワードプレスのセッションで実現
カスタマーには、ショッピングも出来るようにしたい。
× 事情により、プラグインではなく、他のショッピングシステムを使いたい
→ セッションが引き継げないので、ワードプレスでのログイン、ショッピングでのログインと２回、必要になってしまう。

・考えられる解決法
クッキーに保存する
それが危ないからセッションがある訳で、なるべく避けたい。でも、IDだけ引き継ぐのなら良いのかもしれない。その場合は、ショッピングの時に、再ログイン。

２つのセッションを並列して使う
やっちゃいけなそうなので、やってないが、それは思い込みで、これでも出来るのかもしれない。

現状、この辺りで行き詰まっています。
初めての投稿で、多々、粗があると思いますが、
よろしくお願いします。

行動規範の内容に同意します

回答3件

ベストアンサー

いささか混乱もあるようなので、いくつか整理しながら。

「セッション」というのは、一般的には「継続的に情報をやりとりする場所、あるいは一連のやりとり」という意味で、そういう意味では「セッションを張る」と表現することもあります（TCP セッションとか SSH セッションとか) が、ここでの文脈上の「セッション」すなわち HTTP におけるセッションは、普通「セッションを張る」とは言いません。というのも、HTTP 自体はステートレスで（要は一回一回、全部別の通信）あり、プロトコル上に「セッション」の概念がないからです。

そのステートレスな HTTP を使って、でも「継続した一連のやりとり」を実現するのに HTTP セッションと称されるものが利用されるわけですが、一般的な実現方法が Cookie と「サーバ側のストレージ」の組合せのものです。
PHP の場合、デフォルトでファイルシステム上にセッション情報を保存する仕組みが備わっているわけですが、これを独自の実装（セッションハンドラ）に切り替えることも可能です。

Cookie の方も、ご案内のとおり、送信するドメインを自分で決めることができます。たとえば、wordpress を http://wp.example.com/、ZENCART を http://zc.example.com/ に配置している場合、通常はセッション ID を含む cookie はそれぞれのドメインごとに別々に送られるわけですが、session_set_cookie_params でドメインを .example.com に設定することにより、wordpress にも ZENCART にも同一のセッション ID が渡されることになります。
もちろん、同一のセッションが扱えるようになったからといって、その整合性をどうとるか、wordpress でログインしていた場合に ZENCART に自動ログインさせるにはどうすうか、というあたりは、双方のシステムの仕組み対する理解とある程度コーディングは必要になるでしょう。

また、セッションクッキーのドメインを変更しない場合でも、先に挙げたセッションハンドラにカスタマイズ処理を入れることで、一方でログインしたときに他方でログインしたことにする、というのも、可能だと思います。面倒くさそうですけどね。

投稿2016/04/05 03:31

unau

総合スコア2468

mpyw

2016/04/05 05:28

サブドメインで分割されているだけで，同じドメイン部分がある場合にはsession_set_cookie_paramsでドメインを指定する方法が最も簡単だと思います．これが出来ない場合，セッションハンドラにカスタマイズ処理を入れるとありますが，同じリモートIPアドレスに対しては同じセッションIDを発行するように書く…ぐらいしか方法が無さそうに思えます．これはグローバルIPを共有しているマンションなどではセキュリティ的に問題があると思います．ところで，Googleなどは全く別の方法をとっているようです． https://teratail.com/questions/31529 他者の質問から沸いた疑問として私も質問させていただきましたので，よろしければこちらにも回答お願いしますｗ

toranomon

2016/04/05 06:16

unau さん、回答ありがとうございます！セッションについて、詳しい説明ありがとうございます。理解が出来ました。大変、助かります。まだまだ理解が足りませんが、「セッションハンドラ」の共通関数なるものが作れれば、便利そうです。頂いたヒントをもとに、探って行きます。

toranomon

2016/04/05 06:23

CertaiN さん、回答ありがとうございます！同一ドメインなので、「session_set_cookie_params」なるもので、試してみたいと思います。また、「あるドメイン上でログインしただけで別のドメイン上でもログインしたことになる」という，シングルサインオン認証なるものもあるのですね。これだとドメインが違っても情報を共有できそうで、便利そうです。何かヒントでも知っている方がいましたら、こちらと共々、回答を頂けると幸いです。

unau

2016/04/05 09:57

シングルサインオン (SSO) について。 SSO はだいぶ昔 (たぶん 20 年かそこら) からある考え方で実現方法もさまざまですが、ここ数年は下火になってきていて、今後は一部基幹系サービスに細々と残る他は、ブラウザによる入力代行と OAuth2.0 (とその後継) によるサイト間連携に収斂していくんじゃないか、と、もはや業界を引退したおっさんは思うわけであります。たぶん、外れる予想ですが。で、SSO と聞くと、なんとなく 20世紀の話かと思ってしまうのですが、まだまだ使われる用語のようですね。というのはさておき、SSO の実現方式は大きく分けて二つ、一つは代行入力方式、もう一つはサイト信頼方式です（方式の名前は今、適当につけました）。代行入力方式は、サイト A に U さんがログインしたときに、サイト A に保存しておいた U さんの ID・パスワードを使ってサイト A から自動的にサイト B にログインし、発行されたセッション ID を B にユーザに戻してサイト B へログインできるようなタイプのものです。最近のブラウザはパスワードを自動入力してくれるし、そのデータ自体もクラウドで一元管理してくれますよね、で、その情報にアクセスするにはマスターパスワードが必要、みたいな。まあ、そんなイメージで。SSO 用のサーバがリバースプロキシとして間に入る構成もあるようなないような。まあ、そういう構成が取れるなら各サイトの作りは楽ですね、というか特に SSO 対策必要ないですから。一方のサイト信頼方式は、サイト A にユーザ U がログインしてあったとして、(☆) U がサイト B にアクセスしたとき、サイト B からサイト A に「U ってやつからリクエストあったんだけど、こいつログインさせていい？」と問い合わせ、サイト A にログイン済みであれば「いいよ」と返事が返ってくるので、サイト B はサイト A を「信頼」して、U をログイン済みとしてアクセスさせる (☆) というものです。詳細は割愛しますが、(☆) から (☆) までを、リダイレクトを駆使してユーザにはサイト間連携を見せないようにするのが普通です（たぶん）。「サイト A がユーザ U に対して持った信頼」をバックエンドのサーバに保持し、それを「サイト A を信頼しているサイト B」が利用する、という方式もあります。

unau

2016/04/05 10:08

CertaiN さん、私が想定した、SSO 実現のためのカスタムセッションハンドラは、単なるセッション ID 一つに紐付いたセッション情報の保持ではありません。wordpress でログイン成功したら、そこに ZENCART へのリンクを張るわけですが、そこに CSRF 対策よろしく生成したワンタイムトークンも付加するわけです。ZENCART 側に移ったときにトークンも一緒に飛ばされるようにするってことです。で、ZENCART 側では飛んできたトークンを元にセッション情報をサーチし、一致するトークンを保持しているセッション情報があれば、それを利用する、と。ZENCART 側は ZENCART 側で cookie ベースでセッション管理すると便利なので、そのタイミングで cookie 用のセッション ID (こうなってくると ID と呼んでいいのか不明ですが) を払い出すと便利でしょうね。と、特に深く考えるでもなく思いついただけなので、穴はあるかもしれません。

unau

2016/04/05 10:09

CertaiN さんが別に挙げられた質問の方は、他の方がよい回答をされているようですので、私の出る幕はなさそうです。

mpyw

2016/04/05 11:08

詳しいコメントありがとうございました！

mpyw

2016/04/05 22:40

実装してみました http://qiita.com/mpyw/items/904d0692b4594265dbd4

行動規範の内容に同意します