Could not navigate to ... and @PermitAll

Hello all, I’m really struggling with getting my security setup right. I’m trying to integrate with Azure AD B2C.

Using Vaadin Flow 24.3.2, Spring Boot 3.2.0 and spring-cloud-azure-starter-active-directory-b2c 5.8.0. I guess these are the most important libraries.

My security configuration is pretty standard:

public class SecurityConfig extends VaadinWebSecurity{

public SecurityFilterChain configure(HttpSecurity http, AadB2cOidcLoginConfigurer configurer) throws Exception {
    super.configure(http); // will protect all non public / non internal Vaadin endpoints
    http.apply(configurer); // will apply AD B2C integration


This all seems to work fine, if I call my own Restcontroller I can see that my user is properly authenticated. But when I try to invoke a Vaadin view, I get “Could not navigate to…”, essentially a RouteAccessDeniedError is thrown.

@Route(value = “test”, layout = MainLayout.class)
public class TestView extends VerticalLayout {

I did assume this should be enough to get it working? I’m new to Vaadin and I tried to Google the solution for a few hours. Other than some confusing comment about ignoring routes, I haven’t found anything meaningful. Anyone having any idea or what I could try to debug in addition?

So, after debugging how Vaadin applies the security checks, specifically AnnotatedViewAccessChecker, I realized that the PermitAll and the other annotations are not from the java security framework but from some other package.


That was for me not obvious, haven’t spotted a warning or example right away on

Maybe worth adding an example showing the import?

At least I learned a lot about the Vaadin internals. :slightly_smiling_face:

Vaadin 24 (as well as Spring Boot 3) is based on Jakarta EE 10 , meaning that JavaEE packages javax have been migrated to jakarta
More information on the release notes and the migration guide

That’s all fine, but a bit unfortunate if you are just starting. Generally, I appreciate being clear on the classes used, specifically as it doesn’t lead to any compilation issue. It’s just ignored. :slightly_smiling_face: Anyway, just a suggestion.

In the linked docs is a paragraph: “A complete example project, including the source code from this document, is available at” where the GitHub repo contains the Jakarta imports as well :slightly_smiling_face: the interesting question would be, why do you even have those javax imports available, sounds like an issue because since Spring Boot 3 / Vaadin 24 the whole industry changed to the Jakarta world and you shouldn’t have those annotations in your class path

Interesting also because I used the Vaadin template / initalizer application to create the project. :slightly_smiling_face:

Well I guess it is related to my Vaadin application having to talk to a pretty old Glaffish 4 application and in order to connect one usually requires the gf-client jars in their classpath. Again, maybe just a bit unfortunate situation.

Pretty old is an understatement, that’s like ancient :face_with_hand_over_mouth:

You would not believe how well this still works. I grew up with JEE, so maybe a bit nostalgic.

Maybe I should also not mention Vaadin 6.8.17. But hey…

If you have Glassfish 4, you should go with some older version of Vaadin (don’t remember by heart which is the latest Vaadin that works with GF4) and most likely not use Spring (Boot) at all.

Servlet 3.1 that is. So Vaadin 23.3.x might do fine, if your JDK is 11 or newer. If older, then Vaadin 14. Release Vaadin 23.3.0 · vaadin/platform · GitHub

If I understand him correctly, the glass fish is another instance - he just has to talk to :slightly_smiling_face: don’t get him on the path to create yet another legacy app :stuck_out_tongue_closed_eyes:

Ah, skimmed the thread too fast :man_facepalming: Then it is just fixing dependencies in internal libraries.

I’m actually upgrading, step by step. I start replacing the old Vaadin 6 UI. :slightly_smiling_face:

Let me tell you connecting to GF4 from Java 21 was no easy task. At least if you don’t know how. The solution at the end of the day was super simple.

Works like a charm. And I’m not sure if these legacy applications have more complexity than what we sell as modern micro services. That’s a discussion for another thread though.