| hdknr.com's profilehdknrinthespacePhotosBlogLists | Help |
hdknrinthespaceby hdknr.com |
||||||
|
July 03 django: HTTPリクエストをダンプする。def dump_openid_request(request): OpenID 2.0 : Verifying Signatures (署名検証)http://openid.net/specs/openid-authentication-2_0.html#verifying_signatures 11.4. Verifying Signatures (署名検証) If the Relying Party has stored an association with the association handle specified in the assertion, it MUST check the signature on the assertion itself. If it does not have an association stored, it MUST request that the OP verify the signature via Direct Verification (Verifying Directly with the OpenID Provider). RPがアサーションにしめされたアソシエーションハンドルのアソシエーションを保存しているのであれば、アサーションのシグネチャをそれで検証しなければなりません。もしも、アサーションががなければ直接検証によってOPにシグネチャを検証するようにリクエストする必要があります。 11.4.1. Verifying with an Association (アソシエーションの検証:OP)The Relying Party follows the same procedure that the OP followed in generating the signature (Generating Signatures), and then compares the signature in the response to the signature it generated. If the signatures do not match, the assertion is invalid. RPは署名生成の手順と同じ手順にしたがって署名検証をします。署名が一致しなければアサーションは不正です。 If an authentication request included an association handle for an association between the OP and the Relying party, and the OP no longer wishes to use that handle (because it has expired or the secret has been compromised, for instance), the OP will send a response that must be verified directly with the OP, as specified in Section 11.4.2 (Verifying Directly with the OpenID Provider). In that instance, the OP will include the field "openid.invalidate_handle" set to the association handle that the Relying Party included with the original request. 認証要求がOPとRPのアソシーエションのハンドルを含んでいるのであれば、OPはそのハンドルを使いません。OPは応答を直接OPで検証するように返します。openid.invalidate_handleにRPがリクエストに入れたアソシエーションハンドルをセットするのです。 11.4.2. Verifying Directly with the OpenID Provider(OPに直接検証する:RP)To have the signature verification performed by the OP, the Relying Party sends a direct request (Direct Request) to the OP. To verify the signature, the OP uses a private association that was generated when it issued the positive assertion (Positive Assertions). 署名検証をOPにやってもらうためにはダイレクトリクエストを行います。署名を検証するために、OPは先に返答したポジティブ・アサーションに使ったプライベートアソシエーションを使います。 11.4.2.1. Request Parameters
For verifying signatures an OP MUST only use private associations and MUST NOT use associations that have shared keys. If the verification request contains a handle for a shared association, it means the Relying Party no longer knows the shared secret, or an entity other than the RP (e.g. an attacker) has established this association with the OP. OPはプライベートアソシエーションのみを使います。共有キーのあるアソシエーションを使ってはいけません。検証リクストが共有アソシエーションハンドルを含んでいるのであれば、それはRPが共有シークレットを知らないあ、あるいはRP以外(攻撃者)がOPにアソシーエションを確立しようとしているということになります。 To prevent replay attacks, the OP MUST NOT issue more than one verification response for each authentication response it had previously issued. An authentication response and its matching verification request may be identified by their "openid.response_nonce" values. リプレー攻撃を防ぐために、OPは返答した認証応答ごとに1回だけしか検証応答を返答してはいけません。認証応答と対応する検証応答は”openid.response_nonce”で識別できます。 11.4.2.2. Response Parameters
July 01 OpenID Plugin for Wordpress : RP Discoveryがサポートされていない。http://hdknr.ubu/blog/openid/ でXRDをサポートしていないから、らしいです。(@kthrtty) 出力しているテンプレートを見る。 hdknr@LennyOne:~/python-openid-2.2.4/examples/djopenid$ vi templates/server/trust.html {% ifequal trust_root_valid "DISCOVERY_FAILED" %} {% include "server/pape_request_info.html" %} 対応するヴューの処理 hdknr@LennyOne:~/python-openid-2.2.4/examples/djopenid$ vi server/views.py from openid.server.trustroot import verifyReturnTo def showDecidePage(request, openid_request): @type openid_request: openid.server.server.CheckIDRequest try: pape_request = pape.Request.fromOpenIDRequest(openid_request) return direct_to_template( 実際は次のように呼び出し。 verifyReturnTo(http://hdknr.ubu/blog/openid/, 2Fhdknr.deb%2Fserver%2Fuser%2F) _vrfyでDiscoveryFailureが発生。 def verifyReturnTo(realm_str, return_to, _vrfy=getAllowedReturnURLs): This function builds a discovery URL, performs Yadis discovery on @raises DiscoveryFailure: When Yadis discovery fails @since: 2.1.0 if realm is None: try: if returnToMatches(allowable_urls, return_to): デフォルトでは、_vrfyがgetAllowedReturnURLs関数。 from openid.yadis import services def getAllowedReturnURLs(relying_party_url): if rp_url_after_redirects != relying_party_url: return return_to_urls yadis/service.py def getServiceEndpoints(input_url, flt=None): def applyFilter(normalized_uri, xrd_data, flt=None): return endpoints yadis/etxrd.py どうやらtext(xrd_data)がElementTreeでXMLにパースできないもよう。 def parseXRDS(text): @return: ElementTree containing an XRDS document @raises XRDSError: When there is a parse error or the document does return tree ということです。 WordPressでリクエストヘッダーを見てみると。 ( index.php にデバックコードを入れる) Jul 1 17:40:40 ubuntu-vbox OpenID[9446]: APACHE REQUEST HEADER:Accept-Encoding:identity ですので、Acceptにapplication/xrds+xmlがしていされたら、WordPressのトップページでXRDSをダウンロードするようにすれば対応可能でしょう。 PHP: Apacheのリクエストヘッダーをログに書いてしらべるPHPのスクリプトに、次のコードをいれて、tail –f /var/log/messageとかする。 <?php こんな感じ。 root@ubuntu-vbox:/home/sites/hdknr.ubu/wordpress_blog_openid# tail -f /var/log/messages Wordpress: OpenID Plugin
なんどもやってる気がするが。。。。 root@ubuntu-vbox:/home/sites/hdknr.ubu/wordpress_blog_openid/wp-content# cd plugins/ root@ubuntu-vbox:/home/sites/hdknr.ubu/wordpress_blog_openid/wp-content/plugins# unzip openid.3.2.2.zip root@ubuntu-vbox:/home/sites/hdknr.ubu/wordpress_blog_openid/wp-content/plugins# chown -R www-data:www-data openid このあとWordPressの管理画面でプラグインを有効化する。 adminでwp-adminにログインして、OpenIDを使うテストユーザーを作成。 テストユーザーでログインしなおす。 Your OpenID OpenID を指定し、”Add OpenID" OPにAuth Request Possitive Assertionを受けてOpenIDが追加された。 ログオフしてOpenIDでログインしてみる。 できた。 もう一個LiveJournalを追加してみる。 LiveJournalでログインして許可する。 登録できた。 LiveJournalのURLでもログインできます。
|
||||||
|
|
||||||
|
|