Fix AllowedOrigins according to RFC 6454 #875
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
to fail with a
NumberFormatException
when origin stringcontained a character after the port definition like
[port]/
.DefaultCorsProcessor.processRequest
will fail during call toWebUtils.isSameOrigin
.'http://domain1.com' and 'http://domain1.com/' to be different. The same applies to allowed origins comparison. This doesn't meet RFC 6454 standard.
Notes
allowedOrigins
collection can convert providedStrings
directly toUriComponents
or parsing for the headerorigin
andallowedOrigins
can be further simplified.UriComponentsBuilder.fromHttpRequest
but based on the code it may fail the same way asUriComponentsBuilder fromOriginHeader
did. It depends what value can be stored inX-Forwarded-Host
.Issue: Nothing has been reported so far. However, the issue becomes noticeable: SocketRocket
I have signed and agree to the terms of the SpringSource Individual
Contributor License Agreement.