Skip to content

Allow Multipart form POSTs to include access tokens #10553

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

Closed

Conversation

jamietanna
Copy link

@jamietanna jamietanna commented Nov 26, 2021

As part of changes in 6db58cb, we
modified the logic for whether an access token could be sent as a
parameter in a request's body.

However, this doesn't account for Multipart POSTs, for instance where an
image and an access token may be provided together.

This isn't called out as an option for RFC 6750, but is being used in
practice, so we should aim to support it.

In use i.e. by the Micropub standard

As part of changes in 6db58cb, we
modified the logic for whether an access token could be sent as a
parameter in a request's body.

However, this doesn't account for Multipart POSTs, for instance where an
image and an access token may be provided together.

This isn't called out as an option for RFC 6750, but is being used in
practice, so we should aim to support it.
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Nov 26, 2021
@marcusdacoregio marcusdacoregio added in: oauth2 An issue in OAuth2 modules (oauth2-core, oauth2-client, oauth2-resource-server, oauth2-jose) type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged labels Nov 26, 2021
@sjohnr
Copy link
Contributor

sjohnr commented Nov 29, 2021

Hi @jamietanna, thanks for your interest in the project!

Unfortunately, I don't know much about the Micropub standard or the community behind that document, but my understanding is that it is not an internet standards track document, correct?

Unfortunately, this PR seems to regress issue gh-10326, which specifically aligned us with RFC 6750 to avoid issues with multipart form uploads. If support for multipart form uploads is required in your case, I think it would be fairly reasonable to provide your own BearerTokenResolver. In case I'm missing something obvious, can you explain more about your use case and whether it can (or can't) be solved with a custom implementation of BearerTokenResolver?

@sjohnr sjohnr added the status: waiting-for-feedback We need additional information before we can continue label Nov 29, 2021
@jamietanna
Copy link
Author

Hey @sjohnr!

It's been a W3 Recommended standard, but agreed it's not super widely used.

I think that's a very fair point, and I thought I'd raise this PR just to see what your thoughts were - I agree that a custom BearerTokenResolver is the best solution for this 👍

@sjohnr
Copy link
Contributor

sjohnr commented Nov 29, 2021

Thanks @jamietanna for the follow up and understanding!

@sjohnr sjohnr added status: declined A suggestion or change that we don't feel we should currently apply and removed status: waiting-for-feedback We need additional information before we can continue labels Nov 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: oauth2 An issue in OAuth2 modules (oauth2-core, oauth2-client, oauth2-resource-server, oauth2-jose) status: declined A suggestion or change that we don't feel we should currently apply type: enhancement A general enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants