Annotation-Based Access Control
Access annotations on view classes define which users may navigate to a view. They’re the most common way to control access to views. The following annotations are supported:
-
@AnonymousAllowedpermits anyone to navigate to a view without any authentication or authorization. -
@PermitAllallows any authenticated user to navigate to a view. -
@RolesAllowedgrants access to users having the roles specified in the annotation value. -
@DenyAlldisallows everyone from navigating to a view. This is the default: a view without an access annotation behaves as if it had@DenyAll.
The annotations are enforced by navigation access control. In a Spring application, VaadinSecurityConfigurer enables it automatically, as described in Setting Up Spring Security. In other applications, enable it as described in Setting Up Security. Once it’s enabled, none of the views are accessible until one of these annotations — except @DenyAll — is applied to them. For what users see when navigation is denied, see Access-Denied & Not-Found Views.
The following example uses @AnonymousAllowed to let all users navigate to a view:
Source code
Java
@Route(value = "", layout = MainLayout.class)
@PageTitle("Public View")
@AnonymousAllowed
public class PublicView extends VerticalLayout {
// ...
}@PermitAll lets any authenticated user navigate to a view, regardless of their roles:
Source code
Java
@Route(value = "private", layout = MainLayout.class)
@PageTitle("Private View")
@PermitAll
public class PrivateView extends VerticalLayout {
// ...
}@RolesAllowed lets only users with one of the given roles navigate to a view:
Source code
Java
@Route(value = "admin", layout = MainLayout.class)
@PageTitle("Admin View")
@RolesAllowed("ADMIN") // <- Should match one of the user's roles (case-sensitive)
public class AdminView extends VerticalLayout {
// ...
}How role names are matched depends on the application. With Spring Security, they’re matched against the granted authorities, as described in Roles & Authorities. In other applications, they’re passed unchanged to HttpServletRequest.isUserInRole().
Parent Layouts
Access annotations on parent layouts are checked as well. This applies to automatic layouts — classes annotated with @Layout — to parent layouts set with the layout attribute of @Route, and to layouts defined with @ParentLayout. Both the layout and the view must grant access for navigation to succeed. A layout without an access annotation denies access to every view inside it, so a layout that hosts both public and protected views needs @AnonymousAllowed.
Annotation Inheritance
Access annotations are inherited from the closest parent class that has them. Annotating a child class overrides any inherited annotations. Interfaces aren’t checked for annotations, only classes. In the following example, UserListingView requires the ADMIN role:
Source code
Java
@RolesAllowed("ADMIN")
public abstract class AbstractAdminView extends VerticalLayout {
// ...
}
@Route(value = "user-listing", layout = MainLayout.class)
@PageTitle("User Listing")
public class UserListingView extends AbstractAdminView {
// ...
}