Former post form values are now get values

[henning-gerhardt]

I notices that in the most recent versions of the main branch (4.0.x development) that many post form variables are now get parameters. Like

• pages/processes?tab=processTab&filter="id%3A44394"
• pages/processes?filter="stepopen%3AOCR+durchführen"+&sortField=id&showInactiveProjects=false&firstRow=0&tab=processTab&showClosedProcesses=false&sortOrder=desc
• pages/users?tab=usersTab&firstRow=200
• pages/importConfigurationEdit?referrerListOptions=firstRow%3D0%26filter%3D%26sortOrder%3Dasc%26sortField%3Dtitle&id=1
• pages/templateEdit?referrerListOptions=firstRow%3D0%26filter%3D%26sortOrder%3Dasc%26sortField%3Dtitle&id=4&duplicate=true
• projectEdit?referrer=projects&referrerListOptions=firstRow%3D0%26filter%3D%26sortOrder%3Dasc%26sortField%3Dtitle&id=3

and many more.

But this did not happen on the task list page if I enter a search filter or so.

Before I open an issue / bug report I would ask before: Is this intended? I see there some risk if this parameters are so easily editable for any user and I don't know if checking for valid values for this parameters is executed so that the user can not exploit this in any way. Former post values was secured by the JSF mechanism.

@solth @thomaslow pinging both of you as you worked in the recent time on this.

[thomaslow]

But this did not happen on the task list page if I enter a search filter or so.

The PR that updates the task list is not merged yet into main. After PR #6906 is merged, the task list will have the same query parameters.

Before I open an issue / bug report I would ask before: Is this intended?

Yes. Previously, these parameters were managed in the user's session via @SessionScoped beans. While refactoring them to @ViewScoped, see #6456, I implemented the change to URL query parameters, which I believe to be a significant advantage, because now URLs fully represent the view state and can be shared amongst users, e.g. by eMail, or stored as a bookmark. I can imagine that this opens up interesting new use-cases, e.g., sending a link to the process list with a pre-defined filter to a colleague asking for assistance with regards to these processes.

I see there some risk if this parameters are so easily editable for any user and I don't know if checking for valid values for this parameters is executed so that the user can not exploit this in any way.

Yes, URL query parameters are sanitized where appropriate. For example, the filter parameter is not sanitized, because you can enter any text into the filter input field anyway. In contrast, the sortField is sanitized and only accepts the exact fields that can be sorted in the list.

All of the URL query parameters are only controlling how information is queried from the database. There should not be any way to exploit this.

Former post values was secured by the JSF mechanism.

Well. I wouldn't call it "secured". They were hidden from non-expert users. A user may manipulate any of his own post requests before sending it to the server. From this perspective, the "attack surface" should be the same as before.

---

There is one exception I am not entirely happy with. The parameter "referrerListOptions" is an easy way to remember query parameters while navigating between views (to avoid additional concepts like the Flash API). However, I think that URLs should not contain technical information like that, which have no immediate benefit for the user. In this case, it would make sense to hide this information again from users. Since there is already another exception which requires @SessionScoped state (preserving the previous filter query) , I guess it might makes sense to move this parameter into session state again in the future.

[BartChris]

I think this is different from REST APIs which are mostly used by machines, so changes there might break other systems, while a breakage of query params is an inconvience.

On the one hand, a filter which i can store and use in the following days is very nice. On the other hand i can imagine that people might setup Excel lists with all kinds of filters; and of course it would be very bad if all those filters suddenly break. So i find it very hard to decide, what is more important here.

[henning-gerhardt]

From a technical point of view the made changes are correct and must be done. Maybe there are adjustments possible but this is something for the future. Maybe even my doubts are more theoretical than practical so we may go with this changes and see in the future where changes are needed.

[thomaslow]

Okay. So, if query parameters will stay, I'll look into adding a few automated tests to make sure they have the correct effect.

[solth]

Sorry if I was a little rash with merging #6906 , but in my opinion the formulated goal of refactoring the bean scopes was achieved.

@thomaslow Perhaps you could wait until the @kitodo/kitodo-community-board has discussed the topic? I merged the pull request since I didn't want to keep that large pull request in limbo any longer.

If we indeed decide to backtrack on the post parameters (which I don't hope), those adjustments could probably be made afterwards (it might be even easier to make those changes separately than to always update your previous branch with all the changes introduced to the main branch over time, I hope)

[thomaslow]

@solth The community board meeting was yesterday and the protocol says:

CB begrüßt das Feature für komfortable temporäre Abstimmung - Rückbau sollte unbedingt vermieden werden; Vorteile überwiegen!