58. すごいリロード対策

まず、日本のサイトにある一般的な登録フォームの画面遷移は 入力画面→入力確認画面→完了画面 となっている場合が多いようです。ここでリロード問題となるのは完了画面でのDBへのINSERT処理やCSV書き出し処理、メール送信処理など「一度しか行わない処理」です。例えば完了画面へ遷移した際にブラウザのリロードボタンが押された場合、確認画面よりsubmitした情報が再度submitされて上記の一度しか行わない処理が二度行われてしまいます。そうならないよう、リロード対策はスクリプトで制御します。 まずは確認画面のスクリプト 確認画面でチケットを発行し、セッションに保存しておきます。同時に完了画面へチケットがPOSTされるよう、hiddenにセット。こうして完了画面へ遷移させます。それでは完了画面のスクリプトを見てみましょう。 このように、確認画面で発行されたチケットは一度使い切ってしまえば2度処理さ

[mekagazira]

リロード対策

[katt79]

ちょっとずつ勉強していこう。

[behoma_rpei]

リロード

[yuchi]

セキュリティのネタ⇒「完了画面には重要な処理が多くCSRF(クロスサイト・リクエスト・フォージェリー)の問題を抱えている」

[torinanban]

更新を禁止する

[webmarksjp]

php

[unieye51]

【PHP TIPS】 58. すごいリロード対策：ITpro

[takasjsu]

たぶん必要

[bigwest]

リロード対策、これは最低限やること。

[uunfo]

ふつう、当然、あたりまえ。／ひろみちゅがいつも言っているようにSESSION IDを使えばいい。／ちゃんとmt_rand()を使っている。

[ginpei]

セッションを使って二重投稿を防ぐ仕組み。すごいのかな？

[foursue]

うーん。この記事が理解できるまで仕事でコード書かないで欲しい。ただ、そう出来ていない人たちはたくさんいると思うんだけど、どうフォローすりゃあいいのかなあ。

[sourcehoge]

CSRF対策としてなら、自分はこうするな　http://blog.seelz.net/2007/10/19/csrfadhoecaeyeyyooae/

[meets623]

ベタなチケット発行を作っておくのもいいかも

[ibushi]

コントローラーに実装しちゃっておけば楽かも。

[tyamamoto]

すごいのか？

[YoY]

セキュリティ フォーム

[am11op]

自分はこっちだ→http://blog.webcreativepark.net/2007/10/22-011631.html

[swimbird55]

チケット発行によってセッションを保持

[satmat]

あとで

[ag-commerce]

例えば完了画面へ遷移した際にブラウザのリロードボタンが押された場合、確認画面よりsubmitした情報が再度submitされて上記の一度しか行わない処理が二度行われてしまいます。そうならないよう、リロード対策はスクリプ

[nagyurita]

おぎゃー

[kohiro0]

すごい？

[rytich]

sessionにcrumb埋め込んでワンタイムチケット + CSRF対策

[twainy]

ワンタイムチケット

[ikaedih]

リロード対策

[shinfukui]

確かに初めて知った時（Strutsだったか）は「おお、すげー、なるほど」って思ったけど、これをプロが「すごい」と紹介するのはどうなのかと。まぁ、この手の「当たり前品質」が注目されて広まるのは良いことか・・・。

[horixx]

ｐｈｐ

[mingos]

こういう手法をトランザクショントークンと言うのだが、それについては触れられていない。まぁ、開発者にとっては常識なので全然すごくない

[yuanying]

リロード対策は Post -> Redirect -> Get のがいい