Вопрос по libcurl, http, oauth-2.0 – Google API - запрос токена от Oauth2 возвращает «invalid_request»

8

Я пытаюсь создать приложение с помощью API календаря Google. Я следую инструкциямВот, Я могу сделать запрос на получение кода авторизации, но не могу сформировать правильный запрос на получение токена доступа. Я продолжаю получать ответ{"error" : "invalid_request"}. This is the POST request I am making:

POST /o/oauth2/token HTTP/1.1
Host: accounts.google.com
Content-Type: application/x-www-form-urlencoded

code=4/vxQqw9JMYEnXvI8A_93OV7kBSg6h.8r2yJUkMc18dshQV0ieZDAraZNwsbwI&
client_id=[my client id]&
client_secret=[my client secret]&
redirect_uri=http://localhost:8080/auth&
grant_type=authorization_code

Ниже приведен результат вызова URL через curl. Мое настоящее приложение написано в Node.js, но я получаю такой же ответ от curl, как и через приложение. Я искал вокруг и видел людей с похожими проблемами, но все еще не могу понять, что я делаю неправильно.

curl -v -k --header "Content-Type: application/x-www-form-urlencoded" --data-urlencode "code=4/vxQqw9JMYEnXvI8A_93OV7kBSg6h.8r2yJUkMc18dshQV0ieZDAraZNwsbwI&client_id=[my client id]&client_secret=[my client secret]&redirect_uri=http://localhost:8080/auth&grant_type=authorization_code" https://accounts.google.com/o/oauth2/token
* About to connect() to accounts.google.com port 443 (#0)
*   Trying 173.194.74.84... connected
* Connected to accounts.google.com (173.194.74.84) port 443 (#0)
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using RC4-SHA
* Server certificate:
*    subject: C=US; ST=California; L=Mountain View; O=Google Inc; CN=accounts.google.com
*    start date: 2011-07-21 00:00:00 GMT
*    expire date: 2013-07-18 23:59:59 GMT
*    common name: accounts.google.com (matched)
*    issuer: C=ZA; O=Thawte Consulting (Pty) Ltd.; CN=Thawte SGC CA
*    SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> POST /o/oauth2/token HTTP/1.1
> User-Agent: curl/7.21.3 (i386-apple-darwin8.11.1) libcurl/7.21.3 OpenSSL/0.9.7l zlib/1.2.5 libidn/1.17
> Host: accounts.google.com
> Accept: */*
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 180
> 
< HTTP/1.1 400 Bad Request
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: Fri, 01 Jan 1990 00:00:00 GMT
< Date: Tue, 29 May 2012 12:43:49 GMT
< Content-Type: application/json
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< Server: GSE
< Transfer-Encoding: chunked
< 
{
  "error" : "invalid_request"
* Connection #0 to host accounts.google.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
}
@ Thrustmaster Это помогло, спасибо! Использование -F в запросе curl, по крайней мере, дало мне правильный ответ, который позволил мне отладить код моего приложения. stymo
@NachoColoma Извините за задержку. Как я упоминал в приведенном выше комментарии, использование флага -F, как предложил Thrustmaster, позволило мне более эффективно отладить проблему. Детали того, что происходило не так, на самом деле были очень специфичны для моего приложения и, вероятно, не слишком полезны. stymo
Можете ли вы повторить, используя:-F 'code=<code>' -F 'client_id=<id>' -F 'client_secret=<secret>' .... ? Curl URLE закодирует его для вас, вам не нужно это делать. UltraInstinct
Вы поняли это? У меня та же проблема. devnill
Проблема была в том, что вы URLE кодировали уже кодированную строку URLE. Рад, что смог помочь :) UltraInstinct

Ваш Ответ

2   ответа
13

Тело запроса должно быть в одной строке, например:

code=4/vxQqw9JMYEnXvI8A_93OV7kBSg6h.8r2yJUkMc18dshQV0ieZDAraZNwsbwI&client_id=[my client id]&
client_secret=[my client secret]&redirect_uri=http://localhost:8080/auth&grant_type=authorization_code
3

Вы не URL закодировали ваш запрос на публикацию. Я могу сказать по

 redirect_uri=http://localhost:8080/auth

не имея% 99 для двоеточий и косой черты. У меня была такая же проблема с wget. Я думал, что URL закодирует это для меня, но это не так. Кроме того, в вашем пользовательском POST вы не можете иметь переводы строки между амперсандом и значением публикации следующей формы. Все должно быть в одной строке. Это было также моей проблемой с wget.

Вы правы. «Redirect_uri» без "http" вернет & # x201C; invalid_request & # x201D;

Похожие вопросы