You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
After merging #2725, I've noticed that PR had the side effect of increasing these statements in the UI logs:
The response for 'http://localhost:8080/server/api/authz/authorizations/search/object?uri=http%3A%2F%2Flocalhost%3A8080%2Fserver%2Fapi%2Fcore%2Fsites%2F6d65c6a2-3fe7-44dd-bacb-79271257c35d&feature=canSubmit'
has the self link 'http://localhost:8080/server/api/authz/authorizations/search/object?uri=http://localhost:8080/server/api/core/sites/6d65c6a2-3fe7-44dd-bacb-79271257c35d&feature=canSubmit'.
These don't match. This could mean there's an issue with the REST endpoint
The reason is that the UI is comparing one URL that has the RequestParam values all encoded, to one which does NOT have those params encoded. If you look closely, in the statement above, the URLs are identical except for the encoded params.
Simply visit the homepage. You'll see a number of these self link messages appear in the UI logs. The self link actually DOES match the URL, but a simple string comparison fails because of the encoded parameters.
The text was updated successfully, but these errors were encountered:
@alexandrevryghem : Pinging you on this new ticket as it seems to be a side effect of #2725. One simple solution might be to change the logic in this area of the code to do the comparison with both URLs encoded or both URLs decoded:
@tdonohue: Ideally the uri parameter should also be encoded in the backend, but this would be a bigger change. Instead I would maybe simply not encode the uri param in the URL. This was how it worked before PR #2725, because updating the code in DspaceRestResponseParsingService to always decode all the parameters could cause other issues I think:
If you encode all the params from the self link that is returned from the backend, you may potentially encode an already encoded parameter value twice, which will cause them not to match anymore
If you decode all the params from the request URL that you sent, and that the backend returned a self link with encoded params they might also not match anymore
Describe the bug
After merging #2725, I've noticed that PR had the side effect of increasing these statements in the UI logs:
The reason is that the UI is comparing one URL that has the
RequestParam
values all encoded, to one which does NOT have those params encoded. If you look closely, in the statement above, the URLs are identical except for the encoded params.Originally posted by @tdonohue in #2725 (comment)
To Reproduce
Steps to reproduce the behavior:
main
.self link
messages appear in the UI logs. Theself link
actually DOES match the URL, but a simple string comparison fails because of the encoded parameters.The text was updated successfully, but these errors were encountered: