Update CSRF filter to support multipart/form-data payloads

[sberyozkin]

Fixes #28379

[sberyozkin]

I can probably add another test template to produce a multipart/form-data

[sberyozkin]

@FroMage CSRF feature can only partially help when dealing with multipart/form-data - it will help with generating a token and getting it injected into a user template. This is because, as opposed to a form urlencoded payload, reading the multipart payload in the filter and then restoring is not realistic, as most likely it will have file(s) submitted.

But indeed even with large forms reading and restoring can be of concern, so we already recommend in docs in such cases to do the verification in the actual endpoint code - check the form token param against the cookie, but it looks like it does not work yet with RestEasy reactive, so I'll open another issue

[sberyozkin]

Note by default the filter will cover the whole application URI space for POST payloads, and enforce that the forms are url encoded, so a few properties exist to specify which path has to be protected (I made it a Set in this PR), and whether, when the filter verification is enabled, some other payloads should be allowed which is useful in a test where a token verification is required for one method, but for the other one it is delayed till the endpoint is invoked

[sberyozkin]

Tests look good now after the fix from Georgios

[FroMage]

From your code, I don't see where you verify the token automatically for anything but url-encoded forms. It doesn't look like you added support for multipart forms.

As for restoring the forms, I thought you didn't need to do that, since Vert.x was responsible for reading and caching them.

[sberyozkin]

@FroMage Hi,

From your code, I don't see where you verify the token automatically for anything but url-encoded forms. It doesn't look like you added support for multipart forms.

I agree, I was just about to rename the PR, which currently is to verify that the CSRF filter can only help with generating the tokens and having them injected in the template. But...

As for restoring the forms, I thought you didn't need to do that, since Vert.x was responsible for reading and caching them.

changes everything :-), if that is the case then I'll be happy to get rid of the code which restores the forms and that will also help with auto-verification in case of the multipart/form-data, let me try

[sberyozkin]

@FroMage This is very good, thanks, I was able to get rid of the code which restores the form stream, glad you've pointed it out :-)

The tokens in multipart/form-data can also be auto-verified, I've updated the test to check that the flag which is set by the filter in case of the successful verification is available on the context and also kept the code verifying the token in the application code if someone prefers it

[quarkus-bot]

Failing Jobs - Building d63a8c9

Status	Name	Step	Failures	Logs	Raw logs
✔️	JVM Tests - JDK 11
✔️	JVM Tests - JDK 17
✖	JVM Tests - JDK 17 MacOS M1	Set up runner	⚠️ Check →	Logs	Raw logs
✔️	JVM Tests - JDK 18
✖	Quickstarts Compilation - JDK 17	Compile Quickstarts	⚠️ Check →	Logs	Raw logs

[FroMage]

Great!