2012-04-10 7 views
0

Ich schrieb einen einfachen oauth Anbieter und Verbraucher mit dem pecl Oauth-Paket. Alles läuft gut, bis ich versuche, ein Zugriffs-Token zu bekommen, an dem ich einen Fehler bei der Signatur-Übereinstimmung erhalte. Der oauth Verbraucher versucht, den Anbieter zu kontaktieren mit dem oauth-> getauthorizedtoken auf folgende Weise:pecl/oauth vs pecl/oauthprovider Unterschrift nicht übereinstimmen

$res = mysql_query("SELECT * FROM request_tokens WHERE oauth_token = '".mysql_real_escape_string($token)."'"); 
$requestToken = mysql_fetch_assoc($res); 

$oauth->setToken($token, $requestToken['oauth_token_secret']); 
$authToken = $oauth->getAccessToken("http://dev.myserver.com/~testbranch/?m=oauthMod&act=authorize", NULL, $verifier); 

Wenn dies nicht gelingt es spuckt wie mit einem Signatur Debug-Informationen aus:

3qBMmue4Q+j8Dm4/9VSTl6y0TR8= 

Auf der Anbieterseite werden die Verbraucher und Token überprüft und dann scheitert es mit einer Signatur Mismatch obwohl die Signatur berechnet sie ist:

3qBMmue4Q%2Bj8Dm4%2F9VSTl6y0TR8%3D 

die offensichtlich eine uRL ist entkommen Version der exakt gleichen Signatur. Ist das ein Fehler oder fehlt mir offensichtlich etwas?

+0

Wie berechnen Sie die Signatur? Warum ist es urlencodiert? – hakre

+0

Soweit ich das beurteilen kann, erzeugen die beiden OAuth- und OAuth-Provider von pecl die Signatur. Der auf der Anbieterseite generierte Code folgt der http://oauth.net/core/1.0a/#encoding_parameters Spezifikation. Es scheint, dass das Paket nicht den Parameter kodiert? – Nielsvh

+0

Nun, der erste ist nicht codiert, der zweite ist. Allerdings: 'rawurlencode ('3qBMmue4Q + j8Dm4/9VSTl6y0TR8 =') === '3qBMmue4Q% 2Bj8Dm4% 2F9VSTl6y0TR8% 3D';' – hakre

Antwort

0

Wie in meiner Frage erwähnt, sind die beiden Signaturen identisch mit der Ausnahme, dass man die URL codiert ist. Dies ist nicht Teil der Spezifikation und nicht dokumentiert, aber da ist es. Meine endgültige Lösung prüft sowohl auf Signaturübereinstimmungen als auch auf URL-codierte Signaturübereinstimmungen. Dies ist nicht ideal, da es Chancen für falsche Übereinstimmungen gibt, aber ich kann wenig tun, ohne den gesamten Algorithmus von Grund auf neu zu schreiben.

0

OAuthProvider :: $ signature ist der dekodierte Wert von oauth_signature aus der Anfrage des Kunden und nicht die OAuthProvider-berechnete Signatur. Das Drucken des Autorisierungsheaders, der von OAuthProvider empfangen wird, wird also oauth_signature="3qBMmue4Q%2Bj8Dm4%2F9VSTl6y0TR8%3D" enthalten, während OAuthProvider :: $ signature 3qBMmue4Q+j8Dm4/9VSTl6y0TR8= anzeigt.

Wenn Sie das oauth_signature aus dem Authorization-Header (oder gleichwertig) erhalten und es mit einer codierten OAuthProvider :: $ -Signatur vergleichen, werden diese immer übereinstimmen!

Das Problem, das ich mit OAuthProvider hatte, das eine Signatur-Mismatch-Ausnahme auslöst, war das Ergebnis der Bereitstellung des Endpunkt-URI für OAuthProvider :: checkOAuthRequest(). Die Dokumentation gibt an, dass dies optional ist, aber es muss enthalten sein, da es Teil der Signatur-Basiszeichenfolge ist.