Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't send token request body as JSON #244

Closed
RobWilco opened this issue Jul 2, 2016 · 6 comments
Closed

Can't send token request body as JSON #244

RobWilco opened this issue Jul 2, 2016 · 6 comments

Comments

@RobWilco
Copy link

RobWilco commented Jul 2, 2016

Using a grant type of password, when I supply a header of Content-Type: application/json the body is still sent url-encoded instead of as JSON. From the debug logs:

Supplying headers {'Content-Type': 'application/json'} and
  data {'username': 'XXX', 'client_secret': 'XXX',
  'password': 'XXX', 'grant_type': 'password', 'client_id': 'XXX'}

Prepared fetch token request body grant_type=password&username=XXX&
  client_id=XXX&client_secret=XXX&password=XXX

See line 211 below. data=dict(urldecode(body)):

> /Library/Python/2.7/site-packages/requests_oauthlib/oauth2_session.py(210)fetch_token()
-> if method.upper() == 'POST':
(Pdb) l
205             headers = headers or {
206                 'Accept': 'application/json',
207                 'Content-Type': 'application/x-www-form-urlencoded;charset=UTF-8',
208             }
209             self.token = {}
210  ->         if method.upper() == 'POST':
211                 r = self.post(token_url, data=dict(urldecode(body)),
212                     timeout=timeout, headers=headers, auth=auth,
213                     verify=verify)
214                 log.debug('Prepared fetch token request body %s', body)

Other platforms (e.g., ruby) seem to do the right thing. Am I missing something?

@Lukasa
Copy link
Member

Lukasa commented Jul 2, 2016

Why do you need to use JSON? The OAuth2 specification mandates support for application/x-www-form-urlencoded, it should presumably be fine to use that.

@RobWilco
Copy link
Author

RobWilco commented Jul 2, 2016

That's an excellent question. I pointed out that very section of the RFC to the OAuth2 provider. What got me wondering was that they shared a ruby example, and that works (uses a JSON request body). Same with the Authorization header. If that is present it also fails. If it's mandated this may very well be a won't/don't fix sitch.

@Lukasa
Copy link
Member

Lukasa commented Jul 2, 2016

That's very odd. =( So they really don't support form-encoded bodies at all?

@RobWilco
Copy link
Author

RobWilco commented Jul 6, 2016

Agreed, very odd indeed ... unless the implementation I'm being asked to use is of an earlier version.

Update: The project in question is Doorkeeper. I've asked if they truly don't support form-encoded bodies.

@singingwolfboy
Copy link
Member

According to the response on that GitHub issue, it appears that Doorkeeper does support form-encoded bodies. As a result, it sounds like this GitHub issue can be closed. If I'm wrong, and there's more to discuss here, please let me know and reopen this issue.

jamielennox added a commit to jamielennox/requests-oauthlib that referenced this issue Jun 16, 2018
I'm working with an oauth2 server we know is broken, however it works
for other systems and the company has no interest in fixing it. It
requires that I submit auth in JSON format rather than form encoded. We
shouldn't support this specific problem, but if we have a compliance
hook that allows me to change the sending format of the payload as
required I can fix my problem and potentially others in future.

Related to: requests#244 (but not the reason for the patch)
@violuke
Copy link
Contributor

violuke commented Jan 14, 2022

Anyone in this situation in the future. I've added support for this via a new hook in #433. Would be great if this was merged at some point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants