Я использую java, и цель моего демонстрационного приложения проста: обновить статус пользователя. Я выполнил Серверный поток на странице http://developers.facebook.com/docs/authentication. Я получил диалог auth, facebook привел к URL-адресу обратного вызова, и я получил код на моей странице обратного вызова. Затем я потерпел неудачу, когда попытался создать токен доступа.
На странице руководства говорится, что для создания токена доступа можно использовать следующий URL-адрес:
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
Но что происходит в моей среде, я получил следующее сообщение об ошибке:
{
"error": {
"type": "OAuthException",
"message": "Error validating verification code."
}
}
Я уверен, что каждый параметр правильный, потому что, если я изменю параметр client_id или client_secret, у меня появится другое сообщение об ошибке. Параметр кода - это то, что я получил от обратного вызова facebook. Так что это должно быть правильно, не так ли? На самом деле не могу понять, в чем проблема....
Есть идеи об этом? Я застрял здесь...
Недавно я столкнулся именно с этой проблемой: все согласовано, но с ошибкой OAuthException это не получилось. То, что сделало его работу, состояло в том, чтобы изменить перенаправление uri (в обоих запросах на поток):
к
I.e., добавьте конечную косую черту. И тогда это сработало. Глупый и глупый, но там вы идете.
У меня была такая же проблема и я попробовал вышеуказанные предложения. Они помогли, но в моем случае проблема заключалась в том, что у моего redir-URL был параметр запроса, и Facebook не был крут с этим. Итак, мораль истории состоит в том, что redir url, который вы отправили для обмена токеном, должен быть идентичным исходному URL-адресу redir и не может иметь параметры запроса.
Мы тоже немного позаботились об этом.
В нашем случае конечная косая черта в URL-адресе уже была там, поэтому я попробовал токен, который мы использовали в FB Debug Tool, и он подтвержденный, поэтому было похоже, что FB даже не видел токена в запросе.
После некоторого расследования я нашел head-slapper - мы делаем GET с заголовками HTTP только не с Querystring, поэтому FB литерно не видел токена вообще.
Мораль, похоже, заключается в том, что если вы можете получить токен для проверки в средстве отладки FB, в вашем запросе есть вероятность/что-то/нехорошее -
Это может быть отсутствующее "/" или другое несоответствие с URL-адресом, определенным приложением (Domain mistmatch - это другая ошибка). Я не пробовал определять App/Web Url для HTTPS и делать запрос с помощью HTTP, но я подозреваю, что он также будет икотой.
Или, как в нашем случае, метод запроса может быть неправильным - GET с заголовками или POSTing оба выбрасывают 2500, вам нужно выполнить GET с помощью Querystring.
Надеюсь, что это поможет!
У меня была та же проблема. Это была разница в URL, но в отличие от других, которые выложили, моя разница между HTTP и HTTPS.
У нас есть BigIP, обрабатывающий HTTPS-запросы и пересылая сервер HTTP Apache. Когда вызывалась функция BaseFacebook getCurrentUrl(), он обнаружил HTTP, а не оригинальный HTTPS. Я изменил эту функцию следующим образом:
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://';
}
...
Эта версия поддерживает ключ HTTP_PSEUDOSSL. Надеюсь, это поможет кому-то.
Да, трейлинг-слэш помог мне тоже, спасибо!
В целях отладки я счел полезным использовать именно код fb на странице разработчика:
http://developers.facebook.com/docs/authentication/
Как только вы получите это, вы можете изменить его, чтобы он соответствовал вашему собственному коду.
Я не уверен, но вы также можете проверить, правильно ли указаны настройки "URL-адрес сайта" и "Домены сайта" на экране "Редактирование приложений", поскольку согласно документации, redirect_uri должен находиться в том же домене, (Это отличается от URL-адреса страницы холста/вкладки.)
У меня также была проблема с url, но решение для нее было другим. Я передавал signedRequest, который возвращает JavaScript SDK на сервер и используя значение code, чтобы запросить токен доступа. Однако, согласно некоторым комментариям в версии 3.1.1 Facebook PHP SDK, SDK JavaScript связывает code с redirect_uri пустой строки, т.е. "":
// 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
}
}
После того, как я изменил свой собственный код на стороне сервера, чтобы использовать redirect_uri для "", тогда работал запрос на токен доступа.
в моем случае мой код не работал над IE. Проблема была в следующей строке
$user_id = $facebook->getUser();
if ($user_id)
Потому что почему-то функция getUser всегда возвращала 0, так что условие всегда было правдой. Чем он сгенерировал эту ошибку из недействительного токена. Ну, я исправил это, просто сказав это:
if ($user_id>0)
Глупый материал...