2

http://dev.twitter.com/pages/authでウォークスルーを読んでいますが、コールバックURLのエンコードに矛盾があるようです。コールバックは次のようにリストされます：
oauth_callback- http：// localhost：3005 / the_dance / process_callback？service_provider_id = 11

署名の基本文字列は次のように表示されます：
POST＆... oauth_callback％3D http％253A％252F％252Flocalhost％253A3005％252Fthe_dance％252Fprocess_provider_id％253D11％26oauth_consumer_key％3D .. ..

ここでは、コールバックが二重にエンコードされているようです。

署名されたAuthorizationヘッダーは次のようにリストされます：
OAuth oauth_nonce = "QP70eNmVz8jvdPevU3oJD2AfF7R7odC2XJcn4XlZJqk"、oauth_callback = " http ％3A％2F％2Flocalhost％3A3005％2Fthe_dance％2Fprocess_callback％3Fservice_

ここでは、コールバックは単一のURLエンコードされているように見えます。なぜそれらは一貫していないのですか？

4

1 に答える 1

6

エンコーディングに一貫性はありません。URLは、2つの異なる要件を持つ2つの異なる状況で使用されているだけです。

URLは、アプリでエンコードされていない状態から始まります。投稿した2番目の例は、ヘッダーとしてサーバーに渡される値であるため、URLエンコードする必要があります（これは1回です）。

署名されたAuthorizationヘッダーは次のようにリストされます：OAuth oauth_nonce = "QP70eNmVz8jvdPevU3oJD2AfF7R7odC2XJcn4XlZJqk"、oauth_callback = "http％3A％2F％2Flocalhost％3A3005％2Fthe_dance％2Fprocess_callback％3Fservice_

次に、すべてのOAuthヘッダーパラメータの値を他の必要な値と組み合わせて、署名用のベース文字列を作成する必要があります。基本文字列は、サーバーに渡される値から作成されます。したがって、サーバーに渡す値、すでにエンコードされたURLを取得し、それを他の値と組み合わせて、それぞれがURLエンコードされている必要があり、で区切られた新しい文字列を形成し&ます。

ベース文字列の3番目のセクションには、（のように）すでにURLエンコードされた値を持ち、区切り文字としてoauth_callback使用されるクエリパラメータが含まれているため、これを行う必要がある理由がわかります。&このクエリパラメータリスト（を含む&）を安全に（&区切り文字としても使用して）ベース文字列に結合するには、連結する前にURLエンコードする必要があります。この時点で、oauth_callbackは2回エンコードされています。1回は単独で、もう1回はより大きな結合値の一部としてエンコードされています。

署名の基本文字列は次のように表示されます：POST＆... oauth_callback％3Dhttp％253A％252F％252Flocalhost％253A3005％252Fthe_dance％252Fprocess_provider_id％253D11％26oauth_consumer_key％3D .. ..

于 2010-07-20T17:33:50.790 に答える