Open skray opened 2 months ago
I went ahead and opened a PR with my above suggestion just to prove it out as a possibility, but I'm happy to take this any direction needed based on feedback.
@skray I see I'm not the only one that ran into something like this!
TL;DR: I was misled by the POST
on a sandbox web page regarding scopes and urlencoded data vs. json in the body. Leaving this here for posterity.
For the API I'm testing against, they have a sandbox instance, and allow you to get an auth token there to test against the APIs. Looking at that request in the browser, it took the list of scopes requested and concatenated them with '+'s. so, requesting two different scopes, scopeType_A/scopeBranch_A.scope_A
and scopeType_B/scopeBranch_B.scope_B
would send the request in the body like so:
{
"grant_type": "client_credentials",
"scope": "scopeType_A/scopeBranch_A.scope_A+scopeType_B/scopeBranch_B.scope_B"
}
And the header includes Content-Type: application/json
. This returned a valid token.
However, when sending it via the requests_oauthlib
library, the body was url encoded as:
grant_type=client_credentials&scope=scopeType_A%2FscopeBranch_A.scope_A%2BscopeType_B%2FscopeBranch_B.scope_B
and the API I was working against was returning a 401 that the scope was invalid.
While digging into it, I thought it was simply that the urlencode
-ing of the data was what was going wrong, but it turns out that when its sent in this form, it expects spaces instead of plusses.
While digging into this, I found that the code path for parameters ends up in common.py
in oauthlib
, line 233, which automatically encodes the parameters. Trying to figure out if this was requested before, I found an issue on the oauthlib
project asking about the same thing, with the project re-filing it under the requests_oauthlib
lib. Lukasa responded that the API is mandated to support application/x-www-form-urlencoded
by the OAuth2 specification.
Most of that is not terribly relevant to this exact issue, but I wanted to put this somewhere that it might come up in Google searches, and you had a detailed-enough issue that it helped me track this down.
Thanks @zach-flaglerhealth.
To clarify for this issue with Wix, they are very explicitly rejecting x-www-form-urlencoded
bodies with an HTTP 415 response code and a body of
{
"errorCode":409,
"errorDescription":"[business][RECOVERABLE][Hoopoe Core] o.s.w.HttpMediaTypeNotSupportedException - Content type 'application/x-www-form-urlencoded;charset=UTF-8' not supported",
"success":false,
"payload":null
}
The crux of my question below is: Am I correct that there is currently no way to use the
refresh_token_request
to send a JSON payload to the token request endpoint?To explain the issue I am having, Wix's OAuth flow requires access token requests and refreshes to be made using (non-standard) JSON request bodies, instead of the standard
x-www-urlformencoded
body. Documentation for reference:I am able to get the initial access token using the
access_token_request
compliance hook, using a hook very similar to the one described in the PR that introduced the it:However, I am not able to figure out a way to use the
refresh_token_request
compliance hook in a similar way to send a JSON payload. The refresh logic is much more tightly coupled to sending the request payload asx-www-form-urlencoded
, sending only explicit kwargs into theself.post
method, including an expectation that thebody
returned from therefresh_token_request
hook is a urlencoded string. Here is the code in question:So:
x-www-form-urlencoded
body?refresh_token
method andrefresh_token_request
hook to allow this in a non-breaking way. Would something like this be a good start, allowing non-x-www-form-urlencoded
strings to be returned from therefresh_token_request
hook?