10

単純なリダイレクトではなく、自動 HTML 投稿を行うのはなぜですか?

これは、OpenID がわかっている場合にディレクトリをリモート サーバーにポストするログイン フォームを開発者が自動的に生成できるようにするためですか?

例えば。

  1. ユーザーはログインしておらず、ログイン ページにアクセスしています。
  2. Cookie からユーザーの openID を検出します。
  3. リモート OpenID サーバーに直接投稿するフォームが生成されます。
  4. リモート サーバーがユーザーを Web サイトにリダイレクトします。
  5. Web サイトはユーザーをログインさせます。

これが事実なら、私は利益を見ることができます。ただし、これは、ユーザーがログアウトするときにユーザーの openID を Cookie に保持することを前提としています。

この仕様を最適に実装する方法については、ほとんど情報が見つかりません。

公式仕様の HTML FORM リダイレクトを参照してください。

http://openid.net/specs/openid-authentication-2_0.html#indirect_comm

これは、 PHP OpenID Library (バージョン 2.1.1)を調べてわかりました。

// Redirect the user to the OpenID server for authentication.
// Store the token for this authentication so we can verify the
// response.

// For OpenID 1, send a redirect.  For OpenID 2, use a Javascript
// form to send a POST request to the server.
if ($auth_request->shouldSendRedirect()) {
    $redirect_url = $auth_request->redirectURL(getTrustRoot(),
                                               getReturnTo());

    // If the redirect URL can't be built, display an error
    // message.
    if (Auth_OpenID::isFailure($redirect_url)) {
        displayError("Could not redirect to server: " . $redirect_url->message);
    } else {
        // Send redirect.
        header("Location: ".$redirect_url);
    }
} else {
    // Generate form markup and render it.
    $form_id = 'openid_message';
    $form_html = $auth_request->htmlMarkup(getTrustRoot(), getReturnTo(),
                                           false, array('id' => $form_id));

    // Display an error if the form markup couldn't be generated;
    // otherwise, render the HTML.
    if (Auth_OpenID::isFailure($form_html)) {
        displayError("Could not redirect to server: " . $form_html->message);
    } else {
        print $form_html;
    }
}
4

3 に答える 3

7

私はいくつかの理由を考えることができます:

  • 隠すことによるセキュリティのわずかな部分-GETよりもPO​​ST送信を改ざんする方が少し手間がかかります
  • キャッシュと再送信のルールは、GETよりもPO​​STに対してより制限されています。ただし、これがOpenIDのユースケースで問題になるかどうかは完全にはわかりません。
  • ボットはPOSTフォームには従いませんが、リダイレクトには従います。これはサーバーの負荷に影響を与える可能性があります。
  • ブラウザが異なれば、GETリクエストの最大長も異なりますが、POSTほど大きくはありません。
  • 一部のブラウザは、別のドメインへのリダイレクトについて警告します。また、HTTPS以外のURLにPOSTを送信する場合にも警告が表示されます。
  • JavaScriptをオフにすることで、比較的安全なエクスペリエンスを実現でき、サイレントに別のドメインにリダイレクトされることはありません。

送信されるデータの量が一部の主要なブラウザのクエリ文字列の長さを超えない限り、これらのいずれかがPOSTを選択するスラムダンクの理由であるかどうかはわかりません。

于 2008-08-30T13:47:51.220 に答える
6

主な動機は、Mark Brackett が言うように、リダイレクトと GET を使用することによって課されるペイロード サイズの制限でした。一部の実装は、メッセージが特定のサイズを超えた場合にのみ POST を使用するほどスマートです。POST 手法には確かに欠点があるためです。(その中で最も重要なのは、戻るボタンが機能しないという事実です。)引用したサンプルコードのような他の実装は、単純さと一貫性を求めて、その条件を省略します。

于 2008-09-17T17:48:25.357 に答える
4

SAML Web ブラウザ SSO プロファイルにも同じアプローチが使用されます。HTML 投稿リダイレクトを使用する主な理由は次のとおりです。

  • ペイロードの長さは事実上無制限 : SAML では、ペイロードは XMLDSig で署名され、base64 でエンコードされた XML ドキュメントです。これは、URL の通常の 1024 文字制限を超えています (ブラウザーだけでなく、ファイアウォール、リバース プロキシ、ロード バランサーなどの中間ネットワーク デバイスもサポートするためのベスト プラクティスです)。

  • W3C HTTP 標準では、GET はべき等 (同じ URL の GET を複数回実行すると、常に同じ応答が返される) であり、その結果、POST はそうではなく、URL ターゲットに到達する必要がありますが、途中でキャッシュできます。OpenID HTML フォーム POST または SAML HTML フォーム POST の応答はキャッシュされません。認証されたセッションを開始するには、ターゲットに到達する必要があります。

URL クエリは常に変化するので、HTTP GET リダイレクションを使用してもうまくいくと主張することができます。ただし、これは W3C 標準の回避策であるため、標準ではなく、双方が同意する場合は代替実装にする必要があります。

于 2009-03-21T13:26:16.757 に答える