Sso post err

EVE Technology and Research Center Third Party Developers
1

Im using openresty
When I get the authorization code, I always get an error 404 when I send a post request to sso.

image
image1285×312 41.1 KB

openresty log:
2022/03/18 04:13:25 [debug] 29706#0: *63 [lua] http.lua:638: send_request(): {“body”:“grant_type%3Dauthorization_code%26code%3Dmycode”,“path”:"/v2/oauth/toke",“headers”:{“Content-Length”:63,“Authorization”:“Basic somestring”,“User-Agent”:“lua-resty-http/0.12 (Lua) ngx_lua/10020”,“Host”:“login.eveonline.com”,“Content-Type”:“application/x-www-form-urlencoded”},“query”:"",“method”:“POST”}
2022/03/18 04:13:26 [debug] 29706#0: *63 [lua] callback.lua:61: https://login.eveonline.com/v2/oauth/toke

where is the error
Thanks for the kind help

2

Looks like you’re missing the n on your request URI. I.e. /v2/oauth/token not /v2/oauth/toke.

3

thank you for your seriousness
while i change th URI, it returned as 400 {“error”:“invalid_grant”,“error_description”:“Grant type is not supported.”}

4

thank you for your seriousness
while i change th URI, it returned as 400 {“error”:“invalid_grant”,“error_description”:“Grant type is not supported.”}

5

I was always stuck here 400 before

6

curl -XPOST -v -H “Content-Type:application/x-www-form-urlencoded” -H “Authorization:Basic url_safe_base64_string” -d ‘grant_type=authorization_code&code=X00WzkDmt0W86MpDVMWWgA’ https://login.eveonline.com/v2/oauth/token

return {“error”:“invalid_grant”,“error_description”:“Grant type authorization_code is not supported.”}

curl -XPOST -v -H “Content-Type:application/x-www-form-urlencoded” -H “Authorization:Basic url_safe_base64_string” -d ‘grant_type%3Dauthorization_code%26code%3DX00WzkDmt0W86MpDVMWWgA’ https://login.eveonline.com/v2/oauth/token

return {“error”:“invalid_grant”,“error_description”:“Grant type is not supported.”}

where is the diff? and why

7

Hmm, i was able to reproduce this. Give me a few to figure it out.

8

I think the gist of it is your authorization header isn’t right, but the error is less the clear…

To debug this, you should ensure that base64_encode("CLIENT_ID:CLIENT_SECRET") results in Q0xJRU5UX0lEOkNMSUVOVF9TRUNSRVQ=. Which might be as simple as removing the , true on ngx.encode_base64.

9

Thanks for your suggestion, I finally got the correct result .

OAuth 2.0 for Web Based Applications

Create a URL safe Base64 encoded string where the contents before encoding are your application’s client ID, followed by a :, followed by your application’s secret key (e.g. URL safe Base64(<client_id>:<secret_key>)).

not URL safe Base64(<client_id>:<secret_key>), the true just is Base64(<client_id>:<secret_key>)

10

I created a PR to make this clearer in the docs: Clarify Auth header requirements by Blacksmoke16 · Pull Request #68 · esi/esi-docs · GitHub.

In the end I don’t think it really matters if it was URL safe or not given, in my limiting testing, doesn’t ever include those chars anyway. The crux of the problem in your case was the lack of padding.

11

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.