質問 > 管理機能 > 共有SSLの問題を皆で解決しましょう!(というか本当に必要です;) |
管理機能
スレッド表示 | 新しいものから | 前のトピック | 次のトピック | 下へ |
投稿者 | スレッド |
---|---|
nanasess |
投稿日時: 2008/10/27 7:55
対応状況: −−−
|
神 登録日: 2006/9/9 居住地: 投稿: 2324 |
Re: 共有SSLの問題を皆で解決しましょう!(というか本当に必要です;) tonton 様
引用:
transactionid は, LC_Page#getToken() を呼んだ時に, トークンの内容をセッションに保存します. 画面遷移をする際, LC_Page#getToken(), LC_Page#isValidToken() を使用しない場合は, セッションに保存されないため, 差異が発生しているものと思われます. 引用:
セキュリティの面から, 本来なら, 画面遷移するすべての箇所において, transactionid を発行するべきですが, 現在は要所のみの実装となっているためです. 引用:
セッションの dtb_session 保存は, セッションハンドラが勝手にやってくれますので, 特に意識しなくても良いかと思います. 共有SSL で, 非SSL と SSL のページを跨ぐと, Cookie が使えなくなるので, セッションの紐付けができなくなります. 代わりに transactionid を使用することで, 遷移時に一意の値を共有できるので, これにセッションの値を紐付けてやれば良いです. dtb_session に transactionid を格納するカラムを追加しても良いですが, セッションの管理がややこしくなるので, transactionid と シリアライズしたセッションを格納する別のテーブルを用意した方が良さそうです. 1. 非SSL - transactionid を発行し, シリアライズしたセッションを保存 2. SSL - isValidToken() で transactionid を取得し, transactionid と紐付けたセッションを取得, 新たに開始されたセッションを上書き といったイメージですが, 伝わりますでしょうか... |
tonton |
投稿日時: 2008/10/27 11:01
対応状況: −−−
|
仙人 登録日: 2008/8/14 居住地: 投稿: 437 |
Re: 共有SSLの問題を皆で解決しましょう!(というか本当に必要です;) >nanasessさま
お忙しい中、ありがとうございます。 ふむふむ、イメージは、よく分かりました。 そうすると、共有SSLを利用するための正しいと思われる動きは、 1)通常サイトを閲覧始めたときにセッションを開始 2)セッション開始後、transactionidを発行(→共通で呼び出されるphpでgetToken()を実行。または、共通で呼び出されるphpからrequireでgetToken()を実行するphpを呼び出し) 3)isValidToken() で transactionid を取得して、transactionidとセッションをシリアライズし、dtb_transaction(仮称)に、保存(→SC_Healper_Session.phpをコピーして応用?) 4)通常サイトから共通有SSLサイトへ遷移したときに、dtb_transaction(仮称)からシリアル化されたセッション情報を取得してアンシリアライズ。 ということでしょうかね。。。 (3)も(4)も今あるいずれかのphpをコピー&応用でできそうな感じ??? 現状、EC-CUBEでは、非SSLとSSLどちらでページアクセスさせるかは、mtb_constantsがパラメータを持っていて変更可能ですよね。 ということは、SSLサイトになったときに、DBから取得したセッションを上書きするためには、SSL化するページを固定してしまうか(あくまでカスタマイズのルール上の話でいいでしょうが)、または、全体に、SITE_URLおよびSSL_URLと現在のページのURLを比較して、どちらでアクセスしているのかを判定する必要があるということでしょうか。(少なくともmtb_constantsでアクセスを変更可能なページ) または、SSLページのURLは分かっているので、先にSSLあくせすしていなくても、一気にSSLサイトのセッションを上書きするところまでできたらいいのでしょうが、これはできなさそうですね。(当たり前か;) もうちょっと調べてみます。 ありがとうございました。 |
tonton |
投稿日時: 2008/10/27 11:18
対応状況: −−−
|
仙人 登録日: 2008/8/14 居住地: 投稿: 437 |
Re: 共有SSLの問題を皆で解決しましょう!(というか本当に必要です;) >seasoftさま
すみません、こちら、見過ごしてしまってました; レス、再びありがとうございます。 >テンプレートで決め打ちになっている部分は無いですかね? 改めて調べてみます。 >・セッションキーを持たない状態で、HTTPS に GET でアクセスしてきた場合、メイン処理を実行する前の段階で、HTTP のリダイレクトページへリダイレクトする。リダイレクトページ(HTTP)では、セッションキーを引数に HTTPS へ戻す。 つまり、お気に入りとかにHTTPSのURLで何らかのページを保存されていた場合などに必要ということでしょうか。 むむ、いろいろと難しくなってきました; |
seasoft |
投稿日時: 2008/10/27 12:26
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7369 |
Re: 共有SSLの問題を皆で解決しましょう!(というか本当に必要です;) > つまり、お気に入りとかにHTTPSのURLで何らかのページを保存されていた場合などに必要ということでしょうか。
その通りです。他にも検索エンジン、履歴などが考えられると思います。 > むむ、いろいろと難しくなってきました; そうなんですよね。正常系の流れだけなら良いのですが、インターネットに公開するとなると、異常系や脆弱性、ときにはSEOなども考慮しないといけないので面倒なんですよね。
|
tonton |
投稿日時: 2008/10/28 0:32
対応状況: −−−
|
仙人 登録日: 2008/8/14 居住地: 投稿: 437 |
Re: 共有SSLの問題を皆で解決しましょう!(というか本当に必要です;) とりあえず、cookieは使わずにアクセスさせてみて、と思ったところ、大きな問題に出くわしてしまいました。
何か勘違いしてしまっているのかもしれないのですが、mtb_constantsで、useCookieをやめてuseRequestにしたところ、どうも各ページでその都度セッションを発行してしまうようで、買い物カゴも正常に動作しなくなりました; そうすると、cookieを使用しない時点でサイト全体の遷移管理をtransactionidかユニークidを引き継いでやらないといけないことになり、これは、もう、どうにも手に負えないな、という感じです; 仕方がないので、トップページなど通常ページでは、サイドでログインブロックなどをだすのはやめることにして、SSL内でcookieをつかったセッション管理を引き継いでくれれば言い、という方針でやろうかと思うのですが、cartをSSLに移行しても、購入動作の途中で、処理がおかしくなって、トップページへSSL経由でリダイレクトされてしまうので、ここの問題を修復したいと考えています。 ずっと、コードを探っていますが、shopping/deliv.phpからshopping/payment.phpなどへ遷移するときに、共通しておかしいので、やはりLC_Page::sendRedirect()のどうさのなかで、パスの広い方に問題が生じているのだろうというところまでは推測したものの、その部分のPHPのデバッグ方法が分からず、1つやってはまたひとつ悩む状態です;(激泣) しょうがないので、やっぱ専用SSL?と調べていたら、 http://www.godaddy.com/ こんなサイトを見つけてしまいました。 この値段で専用SSLが取れてドメインもホスティングもまかなえるのであれば(但し購入もサポートも英語だけど;)それでいいかなぁと思い出しました。 ただ、自社サイトでは自己責任で、いいですけど、クライアントにはいくら予算がないと言われても勧めにくいですねぇ。。。 一からサーバも手配するクライアントの場合はまあ何とかなるんでしょうが、現在使っているレンタルサーバーでドメインを運用しているから、そこでサブドメインでやりたいとか言われたら、困るんですよね&結構こういうところあるんですよね・・・(再泣) すみません、言いだしっぺなのに、力足らずで全然解決できず・・・ |
seasoft |
投稿日時: 2008/10/29 12:14
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7369 |
Re: 共有SSLの問題を皆で解決しましょう!(というか本当に必要です;) useRequest の場合、PHPの設定変更(tranceid のような名前だったような?)が必要だった気がします。しかし、ドメインの異なるリンクへは自動付加されないような… (設定あるのかな??)
その場合は、SID だったかを手動付加するんだかで対応するのでしょうね。まんま、この仕様を流用しても、キー渡しはできそうですね。逆に私が考えていた方法だと、useRequest で動作するのか、再考の余地がありそうな気もしてきました。
|
WHAT |
投稿日時: 2008/10/31 12:56
対応状況: −−−
|
半人前 登録日: 2008/7/4 居住地: 東京 投稿: 20 |
Re: 共有SSLの問題を皆で解決しましょう!(というか本当に必要です;) あまり専門的な事はわからないのですが…
本題とズレていたら申し訳ありません。 当方、カスタマイズなしで共用SSLを利用してEC CUBEを運用しております。 トップページは共用SSLのURLでインストールすれば可能です。 https://ssl.xxx.yyy.com/~hogehoge/ ただ、この方法では幾つか問題があって、カテゴリページや詳細ページでの追加が出来ないという1つの弱点がありますが、他は問題なく運用できます。 もう1つはログイン機能が通常ページからだと不正な移動と表示されるのですが、これを解決する方法はデザイン上でインラインフレームを使います。 http://hogehoge/index.html ↑通常ファイルの中にインラインフレームで↓を埋め込む https://ssl.xxx.yyy.com/~hogehoge/index.php ログインエリアのみ作成 これで独自ドメイン上の通常htmlファイル上からログインが可能になります。 実は上記で記載した、“カテゴリページや詳細ページでの追加が出来ないという1つの弱点”も階層を1つ落として、もう1つのEC CUBEをインストールする事で、2つめを新規ページ用みたいな感じで行えば、わりとサックリ維持管理が可能です。 もちろん、階層落としてWordpressみたいので実装しても簡単です。 実はサーバーによって、出来たり出来なかったりします。 Coreserver→なぜか出来ない Xserver→上記方法でクリア http://www.xserver.ne.jp/ あと、各種タグの相対値をSSL URLの絶対値にしないとページ移動ごとに警告が出て、ちょっとウザって思うかもしれないので、SSLページではSSL URLの絶対パスで実装するのがポイントです。 他にも制約があって、sslページでは.htaccessが使えないので、mod_rewiteなんかで.htmlにする事はできないです。 この方法で、受注管理、会員登録、キャンペーンページ等の機能はもちろん使えますし、私のお客様のサイトも、EC CUBEの2.2の頃からこの方法で提供し、未だ問題ありませんので、多分大丈夫だと思います。 ご参考になれば。。。 |
tonton |
投稿日時: 2008/11/1 18:03
対応状況: −−−
|
仙人 登録日: 2008/8/14 居住地: 投稿: 437 |
Re: 共有SSLの問題を皆で解決しましょう!(というか本当に必要です;) >seasoftさま
色々思いついてはテストしてみましたが、どれもやっぱり無理でした。nanasessさんがアドバイスくださった方法が一番できそうな気もしますが、自分では難しいな、と思いました; 続けて、リーズナブルに運用できるサーバーも探しながら、思いついたら色々やってみようと思います。 可能な手立てが見つかりましたら、また、書き込みにきますね! |
seasoft |
投稿日時: 2008/11/1 22:38
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7369 |
Re: 共有SSLの問題を皆で解決しましょう!(というか本当に必要です;) 当方の開発環境でも、別ホスト名を割り当てることで、SSL で発生している問題と同じ状況を簡易的にシミュレートできました。
暇なときにでも試そうかと思いますが、色々な環境や状況をカバーするのは難しいですね。とりあえずは、正常系の限られた流れをカバーして、その差分を公開するなどしようかと思います。それに対して、問題点・解決案などを挙げていただき、実際の実装に向けた方向性を模索できればと思います。
|
seasoft |
投稿日時: 2008/11/2 1:25
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7369 |
Re: 共有SSLの問題を皆で解決しましょう!(というか本当に必要です;) たった6行の変更ですが・・・・
引用:
とりあえず、 ・Cookie を使用する設定でサイトを構築する ・HTTPで商品をカートに入れる ・カートから [購入手続きへ] でHTTPSへ遷移する という、遷移はカバーできるようです。
|
« 1 2 3 (4) 5 » |
スレッド表示 | 新しいものから | 前のトピック | 次のトピック | トップ |