2008-08-29 6 views
10

なぜ単純なリダイレクトではなく、自動HTML投稿をしますか?OpenID 2でHTML形式のリダイレクトが使用されるのはなぜですか?

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

例えば、

  1. ユーザーはログインしていないため、ログインページにアクセスしています。
  2. クッキーからユーザーのopenIDを検出します。
  3. リモートOpenIDサーバーに直接ポストするフォームが生成されます。
  4. リモートサーバーはユーザーをウェブサイトにリダイレクトします。
  5. ウェブサイトにログインします。

この場合、私は利益を見ることができます。しかし、これは、ログアウト時にユーザーのopenIDをクッキーに保持していることを前提としています。

この仕様をどのように実装するのが最もよいかに関する情報はほとんど見つかりません。公式スペックで

を参照してください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; 
    } 
} 
+0

http://trac.openidenabled.com/trac/ticket/376を参照してください。 – crb

答えて

6

主な動機は、Mark Brackettが述べたように、リダイレクトとGETを使用してペイロードのサイズを制限したことです。いくつかの実装では、メッセージが特定のサイズを超えたときにPOSTを使用するだけのスマートさがあります。なぜなら、POSTテクニックには明らかに欠点があるからです。 (それらの中の主人公は、あなたの[戻る]ボタンが機能しないという事実です。)あなたが引用したサンプルコードのような他の実装は、シンプルさと一貫性のために、条件付きを省略します。

7

私は理由のカップルの考えることができる:不分明で

  • セキュリティのささやかを - それは
  • キャッシュを取得し、再提出のルールがより制限されているよりも、POSTの提出を改ざんする少しより多くの仕事ですPOSTよりもGETより私は、これがOpenIDユースケースの場合には重要であるとは必ずしも思えません。
  • ボットはPOSTフォームに従わず、リダイレクトに従います。これはサーバーの負荷に影響する可能性があります。
  • ブラウザごとにGETリクエストの最大長さが異なりますが、POSTと同じ大きさのブラウザはありません。
  • 一部のブラウザは、別のドメインにリダイレクトする際に警告します。 HTTPS以外のURLにPOSTを送信している場合は警告も表示されます。
  • JavaScriptをオフにすることで、私は比較的安全なエクスペリエンスを持ち、別のドメインに静かにリダイレクトされることはありません。

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

4

SAML WebブラウザのSSOプロファイルでも同じ方法が使用されます。HTMLポストのリダイレクトを使用する主な動機は、以下のとおりです。ペイロードの

  • 事実上無制限の長さ:SAMLにペイロードがXMLDSIGとbase64エンコードで署名XMLドキュメントです。 URLの通常の1024文字制限よりも大きくなります(ファイアウォール、リバースプロキシ、ロードバランサなどの仲介ネットワークデバイスをサポートするベストプラクティスのみ)。

  • W3C HTTP標準では、GETが冪等である(つまり、複数回実行された同じURL GETは常に同じ応答を返さなければならない)と言われているため、POSTが実行されずにURLターゲットに到達する必要があります。 OpenID HTMLフォームPOSTまたはSAML HTMLフォームの応答POSTはキャッシュされません。認証されたセッションを開始するには、ターゲットに到達する必要があります。あなたは、HTTP GETリダイレクトを使用すると、URLのクエリは、常に変化するので、同様に機能するであろうと、あなたが正しいだろうと主張している可能性があり

は練習です。しかし、これはW3C標準の回避策であるため、両者が同意する場合は、標準ではなく別の実装であるべきです。