Support repeated wildcards in the HTTP permissions path matching patterns

[michalvavrik]

closes: #14047

Until now it was only possible to use wildcard at the end of the path, now you can use it anywhere. Inner wildcard matches exactly one path segment. Behavior for path patterns with ending wildcard or exact path matches didn't change at all.

[michalvavrik]

@stuartwdouglas I'd be truly grateful if you could review this PR when the time is right for you. It's still your path matching algorithm, I just added bit of recursion. So it's still prefix path matching, but /one/*/two/* is divided to /one and the path match contains path matcher for prefix paths behind /*/, here /two.

[github-actions]

🙈 The PR is closed and the preview is expired.

[sberyozkin]

All looks precise to me, lets wait for Stuart @stuartwdouglas to have a quick look too

[sberyozkin]

@michalvavrik Michal, I wonder if it would make sense to add an Important message in the docs, highlighting the importance of testing in general but especially when more than one wildcard is used - to avoid users introducing accidental bypasses.
By the way, I think it can make sense to update the unit test where you check // cases with a few cases of multiple wildcards, I believe by the time this new matcher code is done the path has already been normalized, so a few basic tests will do

[michalvavrik]

@michalvavrik Michal, I wonder if it would make sense to add an Important message in the docs, highlighting the importance of testing in general but especially when more than one wildcard is used - to avoid users introducing accidental bypasses.

That sounds very reasonable. I'll do that.

By the way, I think it can make sense to update the unit test where you check // cases with a few cases of multiple wildcards, I believe by the time this new matcher code is done the path has already been normalized, so a few basic tests will do

@sberyozkin unit test I added to the PathMatchingHttpSecurityPolicyTest is just a smoke test. As long as PathMatcherTest is passing and path is normalized, there is no difference. And the PathMatcherTest tests everything I could think of. So I don't think it is necessary, but it is easy to do and I'll add few other // test cases with multiple wildcards.

[michalvavrik]

Considering I just changed test in different module and docs and previously Hibernate didn't fail, I think integration-tests/hibernate-orm-tenancy/connection-resolver-legacy-qualifiers are unrelated.

[michalvavrik]

Thank you Stuart @stuartwdouglas and Sergey @sberyozkin .

[quarkus-bot]

Failing Jobs - Building bae0f03

Status	Name	Step	Failures	Logs	Raw logs	Build scan
✔️	JVM Tests - JDK 11					🔍
✔️	JVM Tests - JDK 17					🔍
✖	JVM Tests - JDK 21	Build	⚠️ Check →	Logs	Raw logs	🔍

You can also consult the Develocity build scans.

[sberyozkin]

Thanks, JVM21 failure is not related