-
Notifications
You must be signed in to change notification settings - Fork 6k
DefaultBearerTokenResolver triggers processing of multipart content #10326
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
Comments
@regmebaby, thanks for the report. Do you have any interest in submitting a PR to fix the issue in |
@sjohnr Great idea, I'll give it a try |
Before this commit, the DefaultBearerTokenResolver unconditionally resolved the request parameters to check whether multiple tokens are present in the request and reject those requests as invalid. This commit changes this behaviour to resolve the request parameters only if parameter token is supported for the specific request according to spec (RFC 6750). Closes spring-projectsgh-10326
Before this commit, the DefaultBearerTokenResolver unconditionally resolved the request parameters to check whether multiple tokens are present in the request and reject those requests as invalid. This commit changes this behaviour to resolve the request parameters only if parameter token is supported for the specific request according to spec (RFC 6750). Closes gh-10326
Affected Artifact:
Describe the bug
Given that JWT Authentication is configured for a simple Spring Boot Web Application (
http.oauth2ResourceServer(OAuth2ResourceServerConfigurer::jwt);
) and I protect my endpoints (http.authorizeRequests(requests -> requests.mvcMatchers("/api/**").authenticated());
)when I upload a large file to a controller (
@RequestPart(name = "file") MultipartFile file
) without proving a Bearer Token or with invalid Bearer Token (e.g. using Postman)then the large file is uploaded and processed by the application before I receive the response "401 unauthenticated" (e.g. after 7 Minutes, depending on the file size).
Cause:
DefaultBearerTokenResolver
callsresolveFromRequestParameters
even thoughisParameterTokenSupportedForRequest
will be false (asallowFormEncodedBodyParameter
is false by default). The includedrequest.getParameterValues("access_token")
causes the consumption of the whole multipart content.Another Problem: Access Tokens have short life time (e.g. 5 minutes). We found ourselves in the situation that the processing triggered by the resolver (
request.getParameterValues("access_token")
) takes that long that the token is always considered expired by the subsequent logic of theBearerTokenAuthenticationFilter
/JwtAuthenticationProvider
. (Therefore classified as bug)We might want to consider to change the code to resolve from request parameters (and check for multiple bearer tokens in the request) etc. only if
isParameterTokenSupportedForRequest
evaluates true to overcome the outlined two problems.To Reproduce
See Description
Expected behavior
Sample
No sample at hand. Please let me know whether it is necessary to provide one.
The text was updated successfully, but these errors were encountered: