it-swarm.com.de

Zugriffstoken von Facebook nicht abgerufen. Eine OAuthException sagt "Fehler beim Überprüfen des Bestätigungscodes"

Ich verwende Java, und der Zweck meiner Demoanwendung ist einfach: Aktualisieren Sie den Benutzerstatus Ich folgte dem Serverseitigen Flow auf Seite http://developers.facebook.com/docs/authentication . Ich habe den Auth Dialog erhalten, Facebook führt zur Callback-URL und ich habe code auf meiner Callback-Seite. Ich habe dann versagt, wenn ich versuche, ein Zugriffstoken zu generieren. 

Auf der Leitseite heißt es, dass die folgende URL zum Generieren eines Zugriffstokens verwendet werden könnte:

https://graph.facebook.com/oauth/access_token?
     client_id=YOUR_APP_ID&redirect_uri=YOUR_URL&
     client_secret=YOUR_APP_SECRET&code=THE_CODE_FROM_ABOVE

In meiner Umgebung passiert jedoch folgende Fehlermeldung:

{
   "error": {
      "type": "OAuthException",
      "message": "Error validating verification code."
   }
}

Ich bin mir ziemlich sicher, dass jeder Parameter korrekt ist. Wenn ich den client_id-Wert oder den client_secret-Parameter ändere, bekomme ich eine andere Fehlermeldung. Der Code-Parameter ist das, was ich von Facebook-Rückruf erhalten habe. Das sollte also richtig sein, oder? Kann wirklich nicht herausfinden, was das Problem ist ...

Irgendeine Idee dazu? Ich bleibe hier stecken ...

43
DeepNightTwo

Ich habe mich kürzlich genau mit diesem Problem befasst: alles stimmte überein, aber es schlug mit der OAuthException fehl. Die Sache, die es funktionierte, bestand darin, den Umleitungsuri (in beiden Anforderungen für den Fluss) von zu ändern:

http://foo.example.com

zu

http://foo.example.com/

Das heißt, den nachstehenden Schrägstrich hinzufügen. Und dann hat es funktioniert. Dumm und dumm, aber los gehts.

63
Chip

Ich hatte das gleiche Problem und habe die obigen Vorschläge ausprobiert. Sie haben geholfen, aber in meinem Fall bestand das Problem darin, dass meine Redir-URL einen Abfrageparameter aufwies und Facebook damit nicht cool war. Die Moral der Geschichte ist also, dass die Redir-URL, die Sie zum Austausch des Tokens gesendet haben, mit der ursprünglichen Redir-URL identisch sein muss und keine Abfrageparameter enthalten kann.

6
Vinayak Suley

Ich hatte das gleiche Problem. Es war ein Unterschied zwischen den URLs, aber anders als bei den anderen, die geschrieben haben, war bei mir der Unterschied zwischen HTTP und HTTPS.

Wir haben BigIP, der HTTPS-Anforderungen verarbeitet und an einen HTTP-Apache-Server weiterleitet. Beim Aufruf der Funktion getCurrentUrl () von BaseFacebook wurde HTTP und nicht das ursprüngliche HTTPS erkannt. Ich habe diese Funktion wie folgt geändert:

protected function getCurrentUrl() {
    if ((isset($_SERVER['HTTPS']) && ($_SERVER['HTTPS'] == 'on' || $_SERVER['HTTPS'] == 1)) ||
        (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') || 
        (isset($_SERVER['HTTP_PSEUDOSSL']) && $_SERVER['HTTP_PSEUDOSSL'] == 'true')) {
      $protocol = 'https://';
    }
    else {
      $protocol = 'http://';
    }
...

Diese Version unterstützt den Schlüssel HTTP_PSEUDOSSL. Ich hoffe das hilft jemandem.

3
Brad

Wir hatten auch ein bisschen Spaß damit. 

In unserem Fall war der nachstehende Schrägstrich in der URL bereits vorhanden. Daher habe ich das Token, das wir im FB Debug Tool verwendet haben, ausprobiert.

Nach einigen Nachforschungen fand ich den Head-Slapper - wir haben ein GET mit HTTP-Headern nur mit einem Querystring gemacht, so dass die FB das Token überhaupt nicht gesehen hat.

Die Moral scheint zu sein, dass, wenn Sie das Token im FB Debug-Tool zur Validierung bringen können, wahrscheinlich/etwas/falsch in Ihrer Anfrage ist - 

Es kann ein fehlendes "/" oder eine andere Nichtübereinstimmung mit der definierten URL der App sein (Domänennebelmatch ist ein anderer Fehler). Ich habe nicht versucht, die App/Web-URL für HTTPS zu definieren und die Anforderung mit HTTP auszuführen, aber ich vermute, es würde auch irgendwie hiccup.

Oder wie in unserem Fall könnte die Anforderungsmethode falsch sein - GET mit Headern oder POSTing werfen die 2500, Sie müssen GET mit einem Querystring machen.

Hoffentlich hilft das!

3
Serexx

Ja, der nachfolgende Schrägstrich hat auch für mich funktioniert, danke!

Zu Debugging-Zwecken fand ich es hilfreich, genau den Code zu verwenden, den fb auf der Entwicklerseite bereitstellt:

http://developers.facebook.com/docs/authentication/

Sobald das funktioniert, können Sie es an Ihren eigenen Code anpassen.

Ich bin nicht sicher, aber Sie können auch überprüfen, ob Ihre Einstellungen für "Site-URL" und "Site-Domäne" im Bildschirm "App-Bearbeitung" korrekt sind, da sich redirect_uri laut Dokumentation in derselben Domäne befinden muss. (Dies unterscheidet sich von den URLs der Canvas-/Registerseiten.)

2
matt

Ich hatte auch ein URL-Problem, aber die Lösung dafür ist anders. Ich übergab die signedRequest , die das JavaScript SDK an den Server zurückgibt, und verwendete den code-Wert, um ein Zugriffstoken anzufordern. Gemäß einigen Kommentaren in der Version 3.1.1 des Facebook PHP SDK ordnet das JavaScript-SDK die code einem redirect_uri einer leeren Zeichenfolge zu, d. H. "":

// the JS SDK puts a code in with the redirect_uri of ''
if (array_key_exists('code', $signed_request)) {
    $code = $signed_request['code'];
    $access_token = $this->getAccessTokenFromCode($code, '');
    if ($access_token) {
       // etc
    }
}

Nachdem ich meinen eigenen serverseitigen Code geändert habe, um einen redirect_uri von "" zu verwenden, funktionierte die Anforderung für ein Zugriffstoken.

0
user456814

in meinem Fall funktionierte mein Code nicht für IE ..__ Das Problem war in der folgenden Zeile 

$user_id = $facebook->getUser();
if ($user_id)

Weil die getUser-Funktion irgendwie immer 0 zurückgab, so dass diese Bedingung immer wahr war. Dann hat er diesen Fehler aus einem ungültigen Token generiert. Nun, ich habe ihn mit folgenden Worten behoben:

if ($user_id>0)

Dummes Zeug...

0
Diogo Mendonça