Reject "%2F" as an invalid sequence in simp messaging usernames #23836
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.
Current State
Since messaging destinations are delimited by "/", the existing code performs a simple string replacement of "/" -> "%2F" in usernames. This allows usernames which contain "/" to be used and have messaging destinations parsed correctly. See SimpMessagingTemplate.java and DefaultUserDestinationResolver.java
Issue with Current State
Usernames that already contain "%2F" end up with that character sequence converted to a "/" by DefaultUserDestinationResolver. E.g.,
abc%2Fabc
>abc/abc
; however,abc/abc
is not the username, so destination matching fails.Here is an example test that fails, resulting in
(Gradle build scan)
Possible Solutions
(a) Encode all usernames
(b) Encode only usernames that contain characters that need to be encoded and flag the username as encoded so that only encoded usernames are decoded
Sample Solution
A sample solution is included in this pull request using 2(b).
Outstanding Questions
Should an explicit encoding be provided for String > byte[] and byte[] > String? If so, what? UTF-8? Or just let the behavior be undefined if running Java in an environment where the default encoding does not support a particular character?
Other Alternatives
Any feedback is appreciated!
As a note, I recreated this pull request since I didn't branch my fork of the code first or squash commits as recommended by the contribution guidelines.