どうか教えて下さい！
| その他 > その他 > 【開発チームより】オープンソースカンファレンス2009Kansai ブース出展のお知らせ |
その他
 |
| スレッド表示 | 新しいものから | 前のトピック | 次のトピック | 下へ |
| 投稿者 | スレッド |
|---|---|
| nanasess |
投稿日時: 2009/7/11 23:32
対応状況: −−−
|
神   登録日: 2006/9/9 居住地: 投稿: 2313 |
Re: 【開発チームより】オープンソースカンファレンス2009Kansai ブース出展のお知らせ ブースに来ていただいた方, 講演を聞いて下さった方, ありがとうございました!
AMUAMU さん, 実況ありがとうございました! とり急ぎ, 資料を Trac にアップしておきました. http://svn.ec-cube.net/open_trac/wiki |
| tao_s |
投稿日時: 2009/7/12 23:17
対応状況: −−−
|
仙人   登録日: 2008/8/20 居住地: 東京 投稿: 799 |
Re: 【開発チームより】オープンソースカンファレンス2009Kansai ブース出展のお知らせ 行きたかったのに行けなかったのですが、AMUAMUさんの実況とnanasessさんの資料で内容が解り助かりました。
ありがとうございます。 そう言えば今までコミッター申請していなかったので、申請しておきました。（役に立つかどうか不安ですが・・・）
|
| nanasess |
投稿日時: 2009/7/13 10:33
対応状況: −−−
|
神 登録日: 2006/9/9 居住地: 投稿: 2313 |
Re: 【開発チームより】オープンソースカンファレンス2009Kansai ブース出展のお知らせ 引用：
ありがとうございます！！ :) |
| ramrun |
投稿日時: 2009/7/13 13:28
対応状況: −−−
|
仙人  登録日: 2006/11/3 居住地: 投稿: 789 |
Re: 【開発チームより】オープンソースカンファレンス2009Kansai ブース出展のお知らせ この件について、質問ってよいでしょうか？
当日参加できなかった人で、質問したいことがあったりするんじゃないかと思いまして... 個人的にはいま調べているtransactionidの件で、 実際のコードを読むと微妙に機能しておらず、 また機能するように直すとブラウザの「戻る」や「更新」で引っかかります。 このあたり、なにか案はありますでしょうか？ |
| nanasess |
投稿日時: 2009/7/13 14:28
対応状況: −−−
|
神 登録日: 2006/9/9 居住地: 投稿: 2313 |
Re: 【開発チームより】オープンソースカンファレンス2009Kansai ブース出展のお知らせ 引用：
はい, 大丈夫です！ 引用：
具体的な再現ソースを拝見することは可能でしょうか？ # 既出で見落していたらすみません... つっこんだ内容でしたら, コミッターML などでも大丈夫です. |
| ramrun |
投稿日時: 2009/7/13 15:03
対応状況: −−−
|
仙人 登録日: 2006/11/3 居住地: 投稿: 789 |
Re: 【開発チームより】オープンソースカンファレンス2009Kansai ブース出展のお知らせ ありがとうございます。
多分、他の方の方も知っていたほうが良い内容なのではないかと思うのでこちらで。 まず、最初にtransactionid以前の話です。 ・カートに商品が1つ以上入っている ・ブラウザのアドレス欄より/shopping/payment.phpに直接アクセス ・支払い方法を選択し「次へ」 ・確認画面より「注文完了へ」 で、注文できてしまいます。 とりあえずこの件は置いといて。 ここでtransactionidをshopping以降の画面遷移すべてに組み込んでみようと考えたのですが、途中まで進んでブラウザの「戻る」をすると当然「不正なページ処理」となります。 ブラウザの「戻る」だとGETにせよPOSTにせよ、1つ前のtransactionidになると思うので、なんとか両立できないものかというのが1点。 つぎに現在、transactionidをPOSTでのみ利用するよう制限してる場所がいくつかあります。 たとえばshopping/index.phpは本来、カートからPOSTでtransactionidを受けて呼ばれるようになっていますが、実際はGETで/shopping/index.phpにアクセスできます。 同様に/shopping/index.php?from=nonmemberなどもです。 せっかくのtransactionidに穴をあけているような感じで... 規約から会員登録の遷移も、REFERERをチェックしているのであまり活用されている感じじゃないのですが... とりあえずtransactionidとブラウザの「戻る」「進む」を共存させることができないものかというので悩んでいます。 |
| nanasess |
投稿日時: 2009/7/13 15:51
対応状況: −−−
|
神 登録日: 2006/9/9 居住地: 投稿: 2313 |
Re: 【開発チームより】オープンソースカンファレンス2009Kansai ブース出展のお知らせ 引用：
そもそも transactionid は, 「戻る」や「進む」での, アプリケーションが予期しない不正な遷移を防止するためのものなので, 結構難しいですね... やるとしたら, * 購入途中は「戻る」や「進む」を許可 * 購入完了のみ禁止 といった使い方でしょうか. 引用：
このあたりは十分に精査できておらず, 活用できてない部分ですね... 中途半端な実装で申し訳ないですorz 引用：
安直ですが, previous_transactionid とかいう名前でセッションに保存しておくとかですかね. 完了ページ以外は, 1つ前のIDまで有効にするようにしたら実現できそうです. あと, そもそも, 戻るや進むを許可するページは, transactionid を使わないとか. 1.x の実装を, そのまま持ってきた弊害で, 遷移のライフサイクルがごちゃごちゃになっているので, 本来であれば, 1. 自ページへ POST 2. 自ページで業務処理 3. GET で次ページへリダイレクト という PRG パターンにするのが良いんでしょうけどね. |
| ramrun |
投稿日時: 2009/7/13 17:02
対応状況: −−−
|
仙人 登録日: 2006/11/3 居住地: 投稿: 789 |
Re: 【開発チームより】オープンソースカンファレンス2009Kansai ブース出展のお知らせ 引用：
戻るや進むを許可するページは, transactionid を使わないとか. いや、なんだか私がtransactionidをそういうチェックに使おうとしているだけで、実は意味が違ってますか（笑）。 現在はisValidToken()で照合済みtransactionidはsessionからunsetされていて、これは仕組みとして非常に安全な状態だと思います。 transactionidの履歴みたいなのを持つとなると有効期限を設定しなければいけないでしょうし、なんだか規制緩和しているみたいなのがちょっと引っかかるんですよね（汗）。 遷移自体を整理しなければいけないのは、コードを追っていて理解しました。 ちなみに現在のgetToken()は、すでにtransactionidが存在する （getToken()はしたがisValidToken()はしていない）場合は既存のtransactionidをそのまま利用するようになっています。 これはなにか理由があるのでしょうか？ getToken()では常に新しいtransactionidを発行したほうがよいと思うのですが... |
| nanasess |
投稿日時: 2009/7/13 17:19
対応状況: −−−
|
神 登録日: 2006/9/9 居住地: 投稿: 2313 |
Re: 【開発チームより】オープンソースカンファレンス2009Kansai ブース出展のお知らせ ramrun さん,
引用：
いや, 戻るや進むと共存させるには, そうするしかないなぁ... と思っただけです^^; 規制緩和はよろしくないと思います. 引用：
トランザクショントークンの生存期間を getToken() から isValidToken() までと明確にするためです. 1リクエストに必ず1つのみトークンが発行されるようにしています. カスタマイズしていくうちに, 何回も getToken() を呼んでしまったりすると面倒だと思いますし... |
| ramrun |
投稿日時: 2009/7/13 17:30
対応状況: −−−
|
仙人 登録日: 2006/11/3 居住地: 投稿: 789 |
Re: 【開発チームより】オープンソースカンファレンス2009Kansai ブース出展のお知らせ 引用：
カスタマイズしていくうちに, 何回も getToken() を呼んでしまったりすると面倒だと思いますし... あぁ、なるほど。 ログインブロックみたいな存在をすっかり忘れていました。 1つのページにtransactionidを必要とするブロックがいくつか組み込まれる可能性もあるわけですね。 単純に ・Aページ（getToken) → Bページ (isValidToken) ・Cページ (getToken) → Dページ (isValidToken) が ・Aページ (getTolen) → Dページ (isValidToken) というのも有効になりそうだと思ったもので、BページはAからのみ呼び出され、DページはCページからのみ呼び出されるという限定には使えないということでしょうか。 |
| « 1 (2) 3 » | |
| スレッド表示 | 新しいものから | 前のトピック | 次のトピック | トップ |
