Docs

Spring Security Integration

Authentication timing and navigation access-control requirements for Spring browserless tests.

SpringBrowserlessTest integrates the simulated Vaadin environment with Spring Security test authentication. By default, authentication from Spring Security test annotations is available before UI creation and initial navigation, so route access checks observe the test user.

NavigationAccessControl must be registered as a UI BeforeEnterListener for view protection to apply. Spring Boot tests normally receive this setup automatically. A restricted Spring context may need explicit registration through a VaadinServiceInitListener, or a NavigationAccessControl bean together with NavigationAccessControlInitializer.

Authentication Sources

Spring Security test annotations such as @WithMockUser, @WithAnonymousUser, and @WithUserDetails select authentication for individual test methods. They require spring-security-test on the test classpath. @WithUserDetails uses a UserDetailsService from the selected application context.

Authentication established in the test method, or with setupBefore = TestExecutionEvent.TEST_EXECUTION, arrives after initial navigation. The rendered view is not replaced automatically; another navigation applies access control to the new authentication. See Authentication Applied During a Test for the lifecycle contract and the linked test example.

Application Context Isolation

Bean overrides such as @MockitoBean and @MockBean change Spring’s test context cache key. When multiple contexts are used in a suite, the browserless security integration can fail to apply the simulated user during navigation, including in other test classes. For a practical service-substitution approach, see Using a Reduced Application Context.

For simultaneous authenticated users, the application context API maintains security state per user.

For a worked example, see Test View Access Control.

For the procedures previously covered here, see the Building Apps guide.

Session Fixation Protection

Spring Security gives the session a new ID when a user authenticates, and an application without Spring Security does the same by calling HttpServletRequest.changeSessionId() after a successful login. The mocked request performs that rotation instead of refusing it, so a test can drive a login flow that protects against session fixation.

The session itself survives the rotation: the attributes stay, and so does the VaadinSession bound to it. Only the ID changes.

Source code
Java
String idBeforeLogin = VaadinSession.getCurrent().getSession().getId();

// Log in through the application's own flow

Assertions.assertNotEquals(idBeforeLogin,
        VaadinSession.getCurrent().getSession().getId());

2A8B3F1E-9C47-4D5A-B621-8E3F2A7C9D10

Updated