-
Notifications
You must be signed in to change notification settings - Fork 37.7k
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
Avoid opaque to hierarchical reset in UriComponentsBuilder when input is null #24444
Comments
I've edited your comment to improve the formatting. You might want to check out this Mastering Markdown guide for future reference. |
I have verified that the following test fails against @Test
public void replaceQueryWithNull() {
String uri = "urn:ietf:wg:oauth:2.0:oob";
UriComponentsBuilder redirectUriBuilder = UriComponentsBuilder.fromUriString(uri);
redirectUriBuilder.replaceQuery(null);
assertThat(redirectUriBuilder.toUriString()).isEqualTo(uri);
} Commenting out The cause appears to be the fact that @rstoyanchev, what are your thoughts on the matter? |
We can try to improve the behavior in some way. We could for example avoid or defer resetting if what you're setting a component to is |
Thank you! |
The test case is motivated by the behavior of Spring Oauth2 DefaultRedirectResolver. Please see below code excerpt from the class - private String obtainMatchingRedirect(Set<String> redirectUris, String requestedRedirect) {
Assert.notEmpty(redirectUris, "Redirect URIs cannot be empty");
if (redirectUris.size() == 1 && requestedRedirect == null) {
return redirectUris.iterator().next();
}
for (String redirectUri : redirectUris) {
if (requestedRedirect != null && redirectMatches(requestedRedirect, redirectUri)) {
// Initialize with the registered redirect-uri
UriComponentsBuilder redirectUriBuilder = UriComponentsBuilder.fromUriString(redirectUri);
UriComponents requestedRedirectUri = UriComponentsBuilder.fromUriString(requestedRedirect).build();
if (this.matchSubdomains) {
redirectUriBuilder.host(requestedRedirectUri.getHost());
}
if (!this.matchPorts) {
redirectUriBuilder.port(requestedRedirectUri.getPort());
}
redirectUriBuilder.replaceQuery(requestedRedirectUri.getQuery()); // retain additional params (if any)
redirectUriBuilder.fragment(null);
return redirectUriBuilder.build().toUriString();
}
} Note below lines from above code snippet - redirectUriBuilder.replaceQuery(requestedRedirectUri.getQuery());
redirectUriBuilder.fragment(null);
return redirectUriBuilder.build().toUriString(); For opaque URI - public UriComponents build(boolean encoded) {
if (this.ssp != null) {
return new OpaqueUriComponents(this.scheme, this.ssp, this.fragment);
}
else {
return new HierarchicalUriComponents(this.scheme, this.userInfo, this.host, this.port,
this.pathBuilder.build(), this.queryParams, this.fragment, encoded, true);
}
} This breaks the upstream DefaultRedirectResolver obtainMatchingRedirect() code handling redirects for Opaque URIs. |
Thanks for the extra details. Based on this, I will make changes to avoid switching from opaque to hierarchical if the input is |
Could the fix be ported to 4.2.x? Thank you! |
Note that 4.2.x has reached its end-of-life (EOL) several years ago, and even its immediate successor 4.3.x is only supported until the end of 2020. We can consider a backport all the way down to 5.1.x, 5.0.x and 4.3.x but I'm afraid this is as far as we could possibly take it, and even this only if the fix is not expected to have any side effects. Please upgrade at your earliest convenience - at least to 4.3.x. |
@jhoeller Thank you for the update. |
Affects: 4.2.x
Execute below test case and verify the result:
Expected result:
urn:ietf:wg:oauth:2.0:oob
Actual result:
urn:
The text was updated successfully, but these errors were encountered: