Autorisierungsanfrage an Feedly API wirft eine falsche Anfrage mit Guzzle?

Question

Ziel ist es, den Autorisierungscode für das Zugriffs- und Aktualisierungstoken auszutauschen.

Fehler:

GuzzleHttp\Exception\ClientException #400 

Client error response 
[url] http://sandbox.feedly.com/v3/auth/token?code=[auth_code]&client_id=sandbox&client_secret=[secret]&redirect_uri=https%253A%252F%252F[site url]&grant_type=authorization_code&state=%23 
[status code] 400 
[reason phrase] Bad Request 

Verwandte Code:

$client = new GuzzleHttp\Client(); 
$parameters = ['code'=>$_GET['code'],'client_id'=>'sandbox','client_secret'=> '[secret]','redirect_uri'=>urlencode('https://[site url]'),'grant_type'=>'authorization_code', 'state'=>'#']; 
$params = http_build_query($parameters); 
$request = $client->createRequest('POST', 'http://sandbox.feedly.com/v3/auth/token?'.$params); 
$request->addHeader('Accept-Encoding','GZIP'); 
$request->setHeader('Authorization', "auth-code"); 
$request->addHeader('Content-Type','application/json'); 
$response = $client->send($request); 
var_dump($response->json()); 

auch versucht, mit state = "state.passed.in" aber gleichen Fehler wirft.

Können Sie auf den Fehler im Code-Snippet hinweisen. Es verwendet die Feedly API v3 Sandbox und den Guzzle HTTP Client.

Wenn die URL der Anfrage folgt, wird "get not allowed" ausgelöst.

Aktualisiert Code-Schnipsel:

$client = new GuzzleHttp\Client(); 
    $parameters = ['code'=>$_GET['code'],'client_id'=>'sandbox','client_secret'=> '[secret]','redirect_uri'=>urlencode('https://[site url]'),'grant_type'=>'authorization_code', 'state'=>'#']; 
    $params = http_build_query($parameters); 
    $request = $client->createRequest('POST', 'http://sandbox.feedly.com/v3/auth/token?'.$params); 
    $response = $client->send($request); 
    var_dump($response->json()); 

Fehler auf aktualisierten Code:

GuzzleHttp\Exception\ServerException #522 

Server error response [url] http://sandbox.feedly.com/v3/auth/token?code=[auth_code]&client_id=sandbox&client_secret=[secret]&redirect_uri=https%253A%252F%252F[site url]&grant_type=authorization_code&state=%23 
[status code] 522 
[reason phrase] Origin Connection Time-out 

Hinweis: Das Update-Code wird den gleichen Fehler zu werfen (nach ein paar Stunden), das ist

GuzzleHttp\Exception\ClientException #400 

Client error response 
[url] http://sandbox.feedly.com/v3/auth/token?code=[auth_code]&client_id=sandbox&client_secret=[secret]&redirect_uri=https%253A%252F%252F[site url]&grant_type=authorization_code&state=%23 
[status code] 400 
[reason phrase] Bad Request 

Answer 1

Problem: die Umleitungs-URI ist doppelt codiert ist, dass I https%253A%252F%252Fdev10.ritepush.com%252Fdashboard, am Passieren, die an https%3A%2F%2Fdev10.ritepush.com%2Fdashboard dekodiert. Ich muss die uri einmal kodieren, die ich https%3A%2F%2Fdev10.ritepush.com%2Fdashboard übergeben muss.

Grund: PHP kodiert automatisch damit HTTP-Anfragen auf urlencode auf die redirect_uri Anwendung, ich bin kodiert tatsächlich die Umleitung zweimal URI, aber es wird nur einmal decodiert. Daher wird der Encodierungs-URI im Anforderungshauptteil übergeben, was zu dem Fehler führt.

Dank David Chatenay von Feedly für den Fehler hinzuweisen.

Answer 2

Beginnend von unten, gemäß der OAuth 2.0-Spezifikation:

The client MUST use the HTTP "POST" method when making access token requests.

(Quelle: Abschnitt 3.2. The OAuth 2.0 Authorization Framework)

Dies erklärt, warum das Navigieren zur Anforderungs-URL in einem Browser fehlschlägt (Navigationsprobleme werden GET und nur POST Anfragen werden unterstützt).

Der nächste Punkt ist die Client-Authentifizierung, genauer gesagt, wie Sie das bieten client_id und client_secret Parameter, so dass der Server, den Sie zu einer vertrauenswürdigen Client-Anwendung sind validieren kann. Wiederum gemäß der Spezifikation, gibt es zwei Möglichkeiten, diese Informationen weitergegeben werden sollen:

1. Durch HTTP-Basic-Authentifizierungsschema, wie in [RFC2617] definiert, wo die Client-ID als Benutzername und dem Kunden geheim geführt wird als die übergeben wird Passwort. Diese Methode muss von einem OAuth-kompatiblen Server unterstützt werden und ist auch die empfohlene Methode . *
2. Durch die Client-Anmeldeinformationen in der Anfrage-Körper, in der Regel als application/x-www-form-urlencoded codiert (siehe Beispiel unten). Diese Methode ist optional und möglicherweise auf einigen OAuth-Servern nicht verfügbar.

Beispiel der Weitergabe von Clientanmeldeinformationen im Anforderungstext:

POST https://YOUR_NAMESPACE/oauth/token 
Content-type: application/x-www-form-urlencoded 

client_id=YOUR_CLIENT_ID 
&redirect_uri=http://YOUR_APP/callback 
&client_secret=YOUR_CLIENT_SECRET 
&code=AUTHORIZATION_CODE 
&grant_type=authorization_code 

(Quelle: Schrittes vier OAuth Web Application Protocol, klicken Sie auf Plain Verbindungen in Schritt zwei, alle rohen HTTP-Anforderungen in einem vollständigen Berechtigungscode Zuschuss zu sehen flow)

Jetzt, für den Feedly-Anwendungsfall Ich konnte nichts in der Dokumentation über die Unterstützung der HTTP-Standardauthentifizierung finden. Sie sagen folgendes über die Parameter erforderlich, um einen Code für ein Zugriffstoken auszutauschen:

Note: these parameters can either be passed in the URL, as form values, or in a JSON document. If you use a JSON document, make sure you pass the “Content-Type: application/json” header in the request.

(Quelle: Exchanging an auth code for a refresh token and an access token)

Eine Sache, die überraschend ist, dass sie die Client-Anmeldeinformationen zu ermöglichen scheinen passieren in die URL selbst, was eindeutig etwas die OAuth-Spezifikation verbietet:

The parameters (client_id and client_secret) can only be transmitted in the request-body and MUST NOT be included in the request URI.

(Quelle:. Abschnitt 2.3.1 The OAuth 2.0 Authorization Framework)

Schlussfolgernd, sollte gemäß ihrer Dokumentation, was Sie tun es (Übergabe der Parameter in der URL selbst) möglich sein, es sei denn, die Dokumentation ist nicht auf dem neuesten Stand und sie bereits die Nichteinhaltung der Spezifikation und nein behoben länger unterstützen dies.

Darüber hinaus gibt es einige Dinge, die Sie tun, die falsch scheinen. Der Parameter code wird niemals im Header Authorisation übergeben. Wenn Sie also nicht versuchen möchten, die Clientanmeldeinformationen in diesem Header mit der Standardauthentifizierung zu übergeben, würde ich Ihnen vorschlagen, diesen Header zu entfernen.

Ich würde auch den Header Accept-Encoding entfernen, da ihre Dokumente nichts anderes als die Antwort auf eine JSON-Antwort unterstützen. Wenn Sie diese Kopfzeile pflegen möchten, ändern Sie den Wert von gzip in application/json.

Schließlich senden Sie keine Daten im Anforderungstext. Daher möchten Sie möglicherweise auch den Header Content-Type entfernen, da Feedly denken könnte, dass die Daten in der Anforderung anstelle der URL vorhanden sind, wenn dieser Header vorhanden ist .