6

ACSを使用するアプリケーションを構築しています。使用シナリオは次のようになります。

  1. ユーザーはこのようなURLをhttps://our.application.com/?requestId=123456電子メールで取得してクリックします
  2. ユーザーはLiveIDログイン画面にリダイレクトされます
  3. ログイン後、ACSはユーザーを私たちに転送しますが、https： //our.application.com/に転送します

残念ながら、「AccessControlServicePortal」の「RelayingParty」の「ReturnURL」の設定は固定文字列のようです。元のリクエストを伝播する方法はありますか？そうでない場合、回避策として何を提案しますか？

4

3 に答える 3

4

答えは実際にはイエスですが、少しの作業なしではありません。手順3では、リターンURLが、デフォルトのACSログインページによってACSRPで設定されたURLによって上書きされます。これは、ACSがデフォルトでホストするページであり、IDプロバイダーを選択します。（ブラウザに常に表示されるとは限りません。IDPが1つしか設定されていない場合は、自動的にリダイレクトされます。）

この元のURLが保存されるように、自分でホストしているカスタムログインページを使用するようにACSに指示できます。作業用として、ACSポータルからデフォルトのACSログインページをダウンロードできます。

トリッキーな部分は、さまざまなプロトコルを使用するさまざまなIDプロバイダーがさまざまなメカニズムを使用してこの元のURLを保存するという事実に由来します。

これに関するいくつかのさらなる議論とコードサンプルはここで見つけることができます、そしてあなたはウェブの他の場所でこの問題に対するさらなる解決策を見つけるかもしれません：

Azure ACSからログインページをダウンロードした後、リターンURLを正常に機能させるにはどうすればよいですか？

于 2012-08-02T16:27:10.117 に答える
3

答えはノーだと思います。パラメータを保存するためにCookieを使用することをお勧めします。

于 2012-08-02T16:05:24.003 に答える
0

ACS + Microsoftアカウントを介して「returnUrl」を提供する場合は、IdentitiyProviders.jsを介してACSログインページにクエリを実行し、「コンテキスト」を渡すことができます（例：https ：//MyACS.accesscontrol.windows.net/v2/metadata）。 /IdentityProviders.js？protocol = wsfederation＆realm = MyRealm＆reply_to =＆context = foooobar＆request_id =＆version = 1.0＆callback =＆wfresh = 0

その結果、wctxパラメーターを使用してMicrosoftアカウントのLogin-URLを取得し ます。。

ログインプロセスの後、構成されたreturnUrlがwctxパラメーターを使用して呼び出されます（私の例では、「foobar」を取得します）。

于 2013-08-15T12:16:26.087 に答える