いくつかの Web アプリケーション認証プロトコル (WS-Federation や SAML プロトコル、いわゆる「パッシブ」プロトコル、および明らかに ASP.NET フォーム認証も同様です。この StackOverflow questionを参照してください。AppEngine は、この GWT バグ コメントを参照してください)元の「URL フラグメント」、つまり # 記号の後の部分。
おおよそ次のようになります: クリーンなブラウザー (キャッシュされた情報/クッキー/ログイン情報はありません) で、URL (1) http://example.com/myapp/somepage?some=parameter#somewhereを開きます。これにより、ブラウザー リクエスト (2) http://example.com/myapp/somepage?some=parameterが作成され、サーバーが ID プロバイダー (認証リクエストに URL (2) を含む) にリダイレクトし、最終的にリダイレクトされます。元の場所に戻ります。これは URL (2) です。サーバーが認識している唯一の URL です。しかし、私は URL (1) に行きたかったのですが、URL フラグメント (「アンカー」) は途中で失われてしまいました。実際には、最初のステップですでにです。
サーバーは URL フラグメントをまったく認識しないため、これはこれらのプロトコルの根本的な制限のようです。
(1) に移動すると、ブラウザーがサーバーから (2) を要求する仕様によると、SAML プロトコル、WS-Federation などでこのフラグメント損失制限が発生することがわかっています。この制限を回避できますか?
明らかな回避策は、この回答で提案されているように、URL フラグメントを避けることです。ただし、特定の Web アプリケーションの場合は、シングルページ GWT アプリケーションでブックマーク可能な URL フラグメントを使用して、アプリケーション内のナビゲーションによってページがリロードされないようにするため、適切ではありません。
私の質問: この状況には、他にどのような回避策または標準パターンがありますか?
(特に GWT + SAML プロトコル ソリューションに興味があります。)