Closed SunburntRock89 closed 2 years ago
That's weird, access_token
is literally taken from what you can see as raw
, which seems to have it. I will have to test it on my end.
I was just about to say that it works on my end, can you try adding tokens
in:
response: ["tokens", "profile"],
I was just about to say that it works on my end, can you try adding
tokens
in:response: ["tokens", "profile"],
Yep, that fixed it, thanks!
That seems like a bug to me though, I will have to take a look.
As far as I read into it, output
is just whatever is going to be given to the transport (ie saved in session).
So if you've got the tokens
response, there'll be access_token
in the response, but if you don't, output.access_token
is undef and so you end up with grant sending the header:
authorization: Bearer undefined
That's true, but having just the profile
as response option seems like a valid use case to me. It's just that I am not forwarding the token there.
Fair enough
In grant/lib/profile.js, logging
options
:The authorization header defined line 31
options.headers.authorization = `Bearer ${output.access_token}
output.access_token is always undefined, at least when using Discord.If you enable the
raw
response, output.raw.access_token does exist.