Path-matching HTTP Security policy should secure exact path matches for both present and missing ending path separator

[michalvavrik]

Describe the enhancement

For RESTEasy Reactive resource

@Path("/api/users")
public class UsersResource {

    @GET
    @Path("/me")
    @RolesAllowed("user")
    public User me() {
        return new User(identity);
    }
}

both HTTP request paths /api/users/me and /api/users/me/ will be matched, but exact path match quarkus.http.auth.permission.t1.paths=/api/users/me will only match /api/users/me. This seems natural and we document it here https://quarkus.io/version/main/guides/security-authorize-web-endpoints-reference#authorization-using-configuration in a Warning.

But as user, I don't necessary mention every single part of documentation and it doesn't struct me that when I want to secure resource method me I need to add 2 path patterns. I'd go as was as argue that most of the time when you add exact path matches you want to secure both paths.

Also I dare say I don't necessary test both /api/users/me and /api/users/me/.

There are 2 ways I can see to handle this:

• @maxandersen mentioned that in Nginx you can use /api/users/me/? to secure both paths; In that case, we would change documentation to always use ending question mark and only document with proper warning once that when question mark is missing, one path is secured.
• I suggest to secure both paths by default and only allow to override this security first approach with exclamation mark, like /api/users/me! would mean you really want to secure only one path. However that would be breaking change and I can't see it being accepted.

[quarkus-bot]

/cc @sberyozkin (security)