20

PRG patternを使用して、複数のフォームの送信を回避しています。しかし、重大な欠点があります。ユーザーに確認メッセージを表示することはできません(明らかに、ユーザーにはページが表示されず、別のページにリダイレクトされます)。POST + HTTPリダイレクト後にユーザーにメッセージを表示する方法

この問題の解決方法を教えてください。私はそのうちの2つを知っていますが、どれも完璧とは思われません。

  • http://example.com/?msg=data-savedのようなカスタムリダイレクトURLを使用してください。ステートレスなので、かなり信頼できると思います。しかし、ユーザがリンクをコピーしたり、ブックマークしたりするときに問題を引き起こします。
  • セッション変数/クッキーを保存し、すべてのページの読み込み時にチェックします。それが設定されている場合は、それをクリアしてメッセージを表示します。それはOKだと思われますが、私はこのことについてはわかりません。クッキーに強く依存しています。もう少し複雑です。

他にもわからないことがありますか?セッションとURLパラメータの組み合わせダニー。

あなたの意見では、どのような方法が良いですか?どれに欠点が少ないのでしょうか?長所と短所は何ですか?

答えて

1

ユーザーがログインできるようにするウェブサイトのほとんどは、Cookieに依存しています。それは完璧な解決策ではありませんが、私たちが得たベストです。

また、セッション処理は、Web開発フレームワークが一般的に処理するものの1つです。

1

私はセッション変数メソッドを使用します。 URLに表示するためのエラーメッセージ、特にURLの保存/共有の問題を埋め込むことは本当に好きではありません。ユーザーがリンク先のページを再読み込みするときれいなインスタンスになります。

3

実行しているプラ​​ットフォームによって異なります。 [:予告]

は、Ruby on Railsには、このフラッシュ呼び出す= "あなたのアクションが実行された" と、ASP.NET MVCは

基本的には...このTempDataを[ "通知が"] = "あなたのアクションが実行された" とコールし、彼ら単一のラウンドトリップのためだけにHttpSessionにデータを格納するだけです。この方法で、別のWebリクエストでデータを取得できます。

+1

つまり、フレームワークは、Cookieにリンクされたセッションデータストアを使用するという2番目の提案をしばしば受け取ります。 – Eli

8

これに触れる他のいくつかのスタックオーバーフローの質問がありますが、私は問題を非常にはっきりと要約するとは思えません。

便利なソリューションのほとんどは、セッションベースであるか、または(例えば、クエリ文字列内のメッセージを埋め込むなど)より深刻な欠点を有します。

セッションがあることを保証できない場合は、フォーム提出の結果に応じて別のビューにリダイレクトする方法(非常に高価)があります。たとえば、EditWidgetView,EditWidgetSaveSuccessfulView、またはEditWidgetSaveErrorViewにリダイレクトすることができます(エラーの場合はリダイレクトしないことがあります)。いくつかの言語やフレームワークでは、確認/エラーメッセージを表示することをあきらめさせる点では実用的ではありませんが、他の言語やフレームワークでは価値があるかもしれません。

6

何らかの理由でセッションに頼りたくない場合は、変数/カスタムURLを取得し、その変数が存在する場合は参照を確認してください。参照が適切な場合は、メッセージを表示します。はい、これは確認メッセージを表示するために送信された参照に依存しますが、それ以外の場合はセッションに依存しています(信頼性が高く、すべてのソリューションで100%完璧ではありません)。

正直なところ、この種のものについては通常かなり良い大規模サイトは、URLに "actiondone = true"を貼り付けるだけです。 (私はFacebookがいくつかの場所でそれをしない気づいた。)

+0

Refererのトリックはとてもスマートです –

+0

+1 Referer [sic]オプションを使用することを考えていたので、 – Rafa

2

を非常に遅く、この議論に来る..

を次の2つの提案のオプションの組み合わせを使用することができます。

Client: GET http://example.com/foo.cgi 
Server: 200 Ok 

Client: POST http://example.com/bar.cgi 
Server: 303 http://example.com/foo.cgi?msg=true 

msg引数はtrueメッセージがで検索されますされている場合:クライアントは、この要求に対する応答メッセージがあるかもしれないことを示しているURLに(303)リダイレクトされるPOSTリクエストの後

セッションとクライアントへの応答に含まれる(見つかった場合)
引数が! true(存在しない場合)の場合、ルックアップ手順はスキップされます。

このソリューションを使用すると、実際のメッセージがURLに表示されないようにすることができます。URLは、メッセージが存在する可能性があることを示します。また、メッセージは必要なときにのみ表示されます(=セッションで見つかった場合)。

このソリューションでは、HTTPレスポンスに適切なキャッシュコントロールを組み込むこともできます。

+0

セッションデータ内のメッセージの有無をチェックすることでこれを行うことができます各要求)。ここでは_GETパラメータは必要ありません... –

+0

あなたは可能ですが、ブラウザがリソースをキャッシュするのを防ぐことができます – Jacco

関連する問題