DATACMNS-1757 PagedResourcesAssembler generated navigation links ignore non pageable request parameters

[reda-alaoui]

• You have read the Spring Data contribution guidelines.
• There is a ticket in the bug tracker for the project in our JIRA.
• You use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.
• You submit test cases (unit or integration tests) that back your changes.
• You added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).

[reda-alaoui]

Hello?

[reda-alaoui]

Ping :)

[reda-alaoui]

Is there something I can do to ease the merge of this fix?

[mp911de]

I'm not sure we want to include this change because it echos all incoming parameters which open up potential attack vectors. Instead, the page links are intended to remain neutral in terms of the original URL that produced the response.

[reda-alaoui]

Hi @mp911de ,

What kind of attack are you referring to?

the page links are intended to remain neutral in terms of the original URL that produced the response

This is already not the case. prev and next relations are already built based on the original URL that produced the response.

IMO, this is part of the core philosophy of HATEOAS. Ideally, the client should not ever have to build an uri itself, it should only follow relations returned by the server.

Now suppose the server sends a relation referring to /users?page_number=0&page_size=10&fuzzy_name=john to the client. The client does not know how the url has been built. The client does not know that fuzzy_name parameter has been set by the server. The client can only perform a GET on the url.
Without a response containing next relation referring to /users?page_number=1&page_size=10&fuzzy_name=john, the client has no way to fetch the next page.

[mp911de]

I was referring to injection and XSS vulnerabilities. Looking at the outcome of a Spring Data REST repository, we indeed report all query parameters in the self and pagination _links.

Looking at the implementation, parameters seem to be skipped if a baseUri or a base link are provided.

[reda-alaoui]

If you cannot accept it as is, here are alternatives I can think of from most preferred to the least:

• condition the feature on a global option
• condition the feature on a local option
• make the Resolver extensible enough to allow its customization

[mp911de]

Actually, we need to investigate why PagedResourcesAssembler behaves differently between using it with Repositories and the test case you've supplied. Right now, the behavior isn't consistent and after reiterating a bit on this ticket, we should follow your suggestion to include the additional query string options.

[odrotbohm]

See #2173 for details on how we decided to solve this.