Skip to content
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.

Sign up for GitHub

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

Jump to bottom

LinkBuilderSupport.toUri() double-encodes request parameters #1791

Closed
odrotbohm opened this issue May 16, 2022 · 0 comments
Closed

LinkBuilderSupport.toUri() double-encodes request parameters #1791

odrotbohm opened this issue May 16, 2022 · 0 comments
Assignees
@odrotbohm
Labels
in: core Core parts of the project type: bug
Milestone
1.5.1

Comments

@odrotbohm
Copy link
Member

Backport of #1722.
@odrotbohm odrotbohm added type: bug in: core Core parts of the project labels May 16, 2022
@odrotbohm odrotbohm added this to the 1.5.1 milestone May 16, 2022
@odrotbohm odrotbohm self-assigned this May 16, 2022
odrotbohm added a commit that referenced this issue May 16, 2022
@odrotbohm
#1791 - Fix double encoding of request parameters in LinkBuilderSuppo…
7f065cc 
…rt.toUri(…).

We unfortunately cannot use UriComponentsBuilder in a way that we can populate it with encoded parameters *and* expand encoded path variable values. We currently use ….buildAndExpand(…) which considers the values provided unencoded but we never actually call ….toUri() on the resulting UriComponents instance.

We unfortunately cannot fix the problem at its root, as the only alternative would be to call ….build(true) indicating values already encoded but that stumbles above the template variables still present in the original template.

The only workaround right now is never calling UriComponents.toUri() but ….toUriString() as that doesn't apply the pending encoding that's not actually needed as we start with fully encoded values in the first place.
Bert-R added a commit to yonadev/yona-server that referenced this issue Jun 23, 2022
@Bert-R
Provide dummy mobile number for link builder for DOS protection
95e496c 
Due to a change in Spring HATEOAS (spring-projects/spring-hateoas@7f065cc / spring-projects/spring-hateoas#1791), the link builder now parses the URL, so all template parameters have to be bound.
Bert-R added a commit to yonadev/yona-server that referenced this issue Jun 23, 2022
@dependabot @Bert-R
Bump org.springframework.boot from 2.7.0 to 2.7.1 (#875)
a627ac1 
* Bump org.springframework.boot from 2.7.0 to 2.7.1

Bumps [org.springframework.boot](https://github.com/spring-projects/spring-boot) from 2.7.0 to 2.7.1.
- [Release notes](https://github.com/spring-projects/spring-boot/releases)
- [Commits](spring-projects/spring-boot@v2.7.0...v2.7.1)

---
updated-dependencies:
- dependency-name: org.springframework.boot
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>

* Provide dummy mobile number for link builder for DOS protection

Due to a change in Spring HATEOAS (spring-projects/spring-hateoas@7f065cc / spring-projects/spring-hateoas#1791), the link builder now parses the URL, so all template parameters have to be bound.

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Bert Roos <Bert-R@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@odrotbohm odrotbohm

Labels
in: core Core parts of the project type: bug
Projects
None yet
Milestone
1.5.1
Development

No branches or pull requests
1 participant
@odrotbohm