Since they are not by any means a registered route, the result of RouteUtil#isRouteAllowed is false and can cause an unnecessary redirect to the login page even if the user was trying refresh a publicly available view.
It is a bit odd except for the /VAADIN/generated/jar-resources/*, all the other resources should’ve already been ignored by extending VaadinWebSecurity, but still they are not ignored for some reason. This might be a bug, as when I add them again manually to the ignored resources, they are ignored properly.
Shouldn’t the copilot stuff also be added to list of ignored resources by default?
That said, it is normal that RouteUtil#is Route Allowed is called for /VAADIN/xxx. It will return false so the request is evaluated by the next matcher, until it reaches VaadinWebSecurity.getDefaultHttpSecurityPermitMatcher() that allows access.
If the request is blocked it means that some other matcher is engaged
VaadinWebSecurity.getDefaultHttpSecurityPermitMatcher() adds a permitAll() rule for /VAADIN/** , but RouteUtil#isRouteAllowed() is evaluated before it.
Is this due to the order of configuring the http.authorizeHttpRequests(...) before calling the super.configure(http);? Since is it not possible to do it the other way around.
I’m trying to investigate “why sometimes the user is being navigated to login between the dev-mode redeployments, even though, they were at a publicly accessible view when the redeploy is happening”, and wanted see if there’s a way of reducing the noise of calling RouteUtil#isRouteAllowed() when it’s clearly not a route.
Exactly. Currently you can only prepend rules to the Vaadin ones because the configure() method adds the anyReqeust() rule.
It would be nice to add two hooks into VaadinWebSecurity such as prependRequestAuthorization(..) and appendRequestAuthorization() so a developer could choose if put custom rules before or after the ones defined by Vaadin, but anyway before the anyRequest().