Docs

Docs

Spring Security Integration

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

A secured application context integrates the simulated Vaadin environment with Spring Security. Each user carries its own authentication, which is in place before the user’s windows are created and navigate to the root route, so route access checks observe that user. SpringBrowserlessTest takes the authentication of its single user from Spring Security test annotations instead.

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

SpringBrowserlessApplicationContext.createSecured() returns a context whose newUser() overloads set the authentication of each user:

  • newUser() installs an AnonymousAuthenticationToken, like @WithAnonymousUser.

  • newUser(String username, String…​ roles) installs a UsernamePasswordAuthenticationToken in the shape that @WithMockUser produces, adding the ROLE_ prefix to roles that lack it.

  • newUser(Authentication) installs the given authentication, for example one built from a UserDetailsService.

Spring Security test annotations don’t affect the users of a secured context. See Authenticated Users with Spring Security for how the context switches the security context between users.

In SpringBrowserlessTest, 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 after a window has opened — in the test method, through the application’s own login action, or with setupBefore = TestExecutionEvent.TEST_EXECUTION in a base-class test — 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 security integration of SpringBrowserlessTest 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 a worked example, see Test View Access Control.

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