Spring Apache Tiles Do Not Secure Login Updated FREE

Spring Apache Tiles Do Not Secure Login

Leap is considered a trusted framework in the Coffee ecosystem and is widely used. It'due south no longer valid to refer to Bound equally a framework, every bit it'southward more of an umbrella term that covers various frameworks. One of these frameworks is Spring Security, which is a powerful and customizable authentication and authorisation framework. It is considered the de facto standard for securing Spring-based applications.

Despite its popularity, I must admit that when it comes to single-page applications, information technology's not simple and straightforward to configure. I doubtable the reason is that it started more than as an MVC application-oriented framework, where webpage rendering happens on the server-side and communication is session-based.

If the back cease is based on Java and Jump, it makes sense to utilize Jump Security for hallmark/authorization and configure it for stateless communication. While there are a lot of articles explaining how this is done, for me, it was nonetheless frustrating to set up it upward for the first time, and I had to read and sum upward information from multiple sources. That'south why I decided to write this commodity, where I volition try to summarize and embrace all the required subtle details and foibles yous may see during the configuration process.

Defining Terminology

Before diving into the technical details, I want to explicitly define the terminology used in the Spring Security context but to be sure that we all speak the same language.

These are the terms we demand to address:

• Authentication refers to the process of verifying the identity of a user, based on provided credentials. A common example is entering a username and a countersign when yous log in to a website. You can think of it as an respond to the question Who are you?.
• Authorization refers to the process of determining if a user has proper permission to perform a item action or read item data, assuming that the user is successfully authenticated. You can think of it as an reply to the question Tin a user do/read this?.
• Principle refers to the currently authenticated user.
• Granted authority refers to the permission of the authenticated user.
• Role refers to a group of permissions of the authenticated user.

Creating a Basic Bound Application

Before moving to the configuration of the Leap Security framework, let'south create a basic Spring spider web application. For this, nosotros can apply a Spring Initializr and generate a template project. For a uncomplicated spider web awarding, simply a Spring spider web framework dependency is enough:

          <dependencies>     <dependency>         <groupId>org.springframework.boot</groupId>         <artifactId>spring-boot-starter-web</artifactId>     </dependency> </dependencies>                  

One time nosotros have created the project, we can add together a uncomplicated Residue controller to it equally follows:

          @RestController @RequestMapping("howdy") public grade HelloRestController {      @GetMapping("user")     public String helloUser() {         return "How-do-you-do User";     }      @GetMapping("admin")     public String helloAdmin() {         render "Hullo Admin";     }  }                  

Subsequently this, if we build and run the project, nosotros tin admission the following URLs in the web browser:

• http://localhost:8080/how-do-you-do/user will return the string Hi User.
• http://localhost:8080/how-do-you-do/admin will return the cord Hello Admin.

Now, we can add the Spring Security framework to our projection, and nosotros can do this by adding the post-obit dependency to our pom.xml file:

          <dependencies>     <dependency>       <groupId>org.springframework.kick</groupId>       <artifactId>spring-boot-starter-security</artifactId>     </dependency> </dependencies>                  

Adding other Spring framework dependencies doesn't normally accept an immediate effect on an application until we provide the corresponding configuration, but Spring Security is different in that information technology does take an firsthand result, and this ordinarily confuses new users. After adding information technology, if nosotros rebuild and run the project and and so try to access one of the aforementioned URLs instead of viewing the result, we will be redirected to http://localhost:8080/login. This is default beliefs because the Spring Security framework requires authentication out of the box for all URLs.

To pass the authentication, nosotros can utilize the default username user and find an car-generated password in our console:

          Using generated security password: 1fc15145-dfee-4bec-a009-e32ca21c77ce                  

Please call up that the password changes each time we rerun the application. If we want to alter this behavior and make the password static, we can add the following configuration to our application.properties file:

          spring.security.user.password=Test12345_                  

Now, if we enter credentials in the login form, we will be redirected back to our URL and we will see the correct result. Please annotation that the out-of-the-box authentication process is session-based, and if we desire to log out, we can access the following URL: http://localhost:8080/logout

This out-of-the-box behavior may exist useful for classic MVC web applications where we take session-based hallmark, but in the case of single-page applications, it'due south usually not useful because in most employ cases, we have client-side rendering and JWT-based stateless authentication. In this instance, we will have to heavily customize the Spring Security framework, which we will do in the remainder of the article.

As an example, we volition implement a classic bookstore web awarding and create a back end that will provide Grime APIs to create authors and books plus APIs for user management and authentication.

Leap Security Architecture Overview

Earlier nosotros start customizing the configuration, let'due south first discuss how Spring Security authentication works behind the scenes.

The following diagram presents the period and shows how hallmark requests are processed:

Bound Security Architecture

Now, let'due south suspension downward this diagram into components and discuss each of them separately.

Spring Security Filters Chain

When you add the Spring Security framework to your application, it automatically registers a filters chain that intercepts all incoming requests. This chain consists of various filters, and each of them handles a detail use case.

For case:

• Bank check if the requested URL is publicly accessible, based on configuration.
• In case of session-based authentication, check if the user is already authenticated in the current session.
• Check if the user is authorized to perform the requested activity, and so on.

One important detail I want to mention is that Jump Security filters are registered with the lowest order and are the start filters invoked. For some utilize cases, if you want to put your custom filter in front of them, yous will need to add together padding to their social club. This can be done with the following configuration:

          bound.security.filter.order=x                  

In one case we add together this configuration to our application.properties file, we will have infinite for 10 custom filters in front of the Spring Security filters.

AuthenticationManager

You tin recollect of AuthenticationManager equally a coordinator where you tin register multiple providers, and based on the request type, information technology will deliver an authentication request to the correct provider.

AuthenticationProvider

AuthenticationProvider processes specific types of hallmark. Its interface exposes simply two functions:

• cosign performs authentication with the request.
• supports checks if this provider supports the indicated authentication type.

Ane important implementation of the interface that we are using in our sample project is DaoAuthenticationProvider, which retrieves user details from a UserDetailsService.

UserDetailsService

UserDetailsService is described as a core interface that loads user-specific information in the Leap documentation.

In most employ cases, authentication providers extract user identity information based on credentials from a database and then perform validation. Because this use instance is and then common, Spring developers decided to extract information technology as a separate interface, which exposes the single role:

• loadUserByUsername accepts username every bit a parameter and returns the user identity object.

Authentication Using JWT with Spring Security

Afterward discussing the internals of the Spring Security framework, let'due south configure it for stateless authentication with a JWT token.

To customize Spring Security, we need a configuration class annotated with @EnableWebSecurity notation in our classpath. Also, to simplify the customization process, the framework exposes a WebSecurityConfigurerAdapter course. We will extend this adapter and override both of its functions and so as to:

1. Configure the hallmark manager with the right provider
2. Configure web security (public URLs, private URLs, authorization, etc.)

          @EnableWebSecurity public class SecurityConfig extends WebSecurityConfigurerAdapter {      @Override     protected void configure(AuthenticationManagerBuilder auth) throws Exception {         // TODO configure hallmark manager     }      @Override     protected void configure(HttpSecurity http) throws Exception {         // TODO configure web security     }  }                  

In our sample application, we store user identities in a MongoDB database, in the users collection. These identities are mapped by the User entity, and their CRUD operations are defined by the UserRepo Leap Data repository.

Now, when we accept the hallmark request, we demand to recall the correct identity from the database using the provided credentials and then verify it. For this, we need the implementation of the UserDetailsService interface, which is divers as follows:

          public interface UserDetailsService {      UserDetails loadUserByUsername(String username)             throws UsernameNotFoundException;  }                  

Here, we can run into that it is required to return the object that implements the UserDetails interface, and our User entity implements it (for implementation details, delight see the sample project's repository). Considering the fact that it exposes just the single-part prototype, we can treat information technology as a functional interface and provide implementation as a lambda expression.

          @EnableWebSecurity public course SecurityConfig extends WebSecurityConfigurerAdapter {      private final UserRepo userRepo;      public SecurityConfig(UserRepo userRepo) {         this.userRepo = userRepo;     }      @Override     protected void configure(AuthenticationManagerBuilder auth) throws Exception {         auth.userDetailsService(username -> userRepo             .findByUsername(username)             .orElseThrow(                 () -> new UsernameNotFoundException(                     format("User: %s, not establish", username)                 )             ));     }      // Details omitted for brevity  }                  

Here, the auth.userDetailsService function telephone call will initiate the DaoAuthenticationProvider instance using our implementation of the UserDetailsService interface and annals it in the hallmark director.

Along with the authentication provider, we need to configure an hallmark manager with the correct password-encoding schema that will exist used for credentials verification. For this, we demand to expose the preferred implementation of the PasswordEncoder interface as a bean.

In our sample projection, nosotros will use the bcrypt password-hashing algorithm.

          @EnableWebSecurity public course SecurityConfig extends WebSecurityConfigurerAdapter {      private terminal UserRepo userRepo;      public SecurityConfig(UserRepo userRepo) {         this.userRepo = userRepo;     }      @Override     protected void configure(AuthenticationManagerBuilder auth) throws Exception {         auth.userDetailsService(username -> userRepo             .findByUsername(username)             .orElseThrow(                 () -> new UsernameNotFoundException(                     format("User: %south, non found", username)                 )             ));     }      @Bean     public PasswordEncoder passwordEncoder() {         render new BCryptPasswordEncoder();     }      // Details omitted for brevity  }                  

Having configured the authentication director, we now need to configure web security. We are implementing a REST API and need stateless authentication with a JWT token; therefore, we need to gear up the post-obit options:

• Enable CORS and disable CSRF.
• Set session management to stateless.
• Set unauthorized requests exception handler.
• Gear up permissions on endpoints.
• Add JWT token filter.

This configuration is implemented as follows:

          @EnableWebSecurity public form SecurityConfig extends WebSecurityConfigurerAdapter {      individual final UserRepo userRepo;     private final JwtTokenFilter jwtTokenFilter;      public SecurityConfig(UserRepo userRepo,                           JwtTokenFilter jwtTokenFilter) {         this.userRepo = userRepo;         this.jwtTokenFilter = jwtTokenFilter;     }      // Details omitted for brevity      @Override     protected void configure(HttpSecurity http) throws Exception {         // Enable CORS and disable CSRF         http = http.cors().and().csrf().disable();          // Fix session management to stateless         http = http             .sessionManagement()             .sessionCreationPolicy(SessionCreationPolicy.STATELESS)             .and();          // Set unauthorized requests exception handler         http = http             .exceptionHandling()             .authenticationEntryPoint(                 (request, response, ex) -> {                     response.sendError(                         HttpServletResponse.SC_UNAUTHORIZED,                         ex.getMessage()                     );                 }             )             .and();          // Set permissions on endpoints         http.authorizeRequests()             // Our public endpoints             .antMatchers("/api/public/**").permitAll()             .antMatchers(HttpMethod.GET, "/api/author/**").permitAll()             .antMatchers(HttpMethod.POST, "/api/author/search").permitAll()             .antMatchers(HttpMethod.Go, "/api/book/**").permitAll()             .antMatchers(HttpMethod.POST, "/api/book/search").permitAll()             // Our private endpoints             .anyRequest().authenticated();          // Add JWT token filter         http.addFilterBefore(             jwtTokenFilter,             UsernamePasswordAuthenticationFilter.class         );     }      // Used by leap security if CORS is enabled.     @Bean     public CorsFilter corsFilter() {         UrlBasedCorsConfigurationSource source =             new UrlBasedCorsConfigurationSource();         CorsConfiguration config = new CorsConfiguration();         config.setAllowCredentials(true);         config.addAllowedOrigin("*");         config.addAllowedHeader("*");         config.addAllowedMethod("*");         source.registerCorsConfiguration("/**", config);         render new CorsFilter(source);     }  }                  

Please note that we added the JwtTokenFilter before the Spring Security internal UsernamePasswordAuthenticationFilter. We're doing this because we need admission to the user identity at this point to perform authentication/authorization, and its extraction happens inside the JWT token filter based on the provided JWT token. This is implemented every bit follows:

          @Component public class JwtTokenFilter extends OncePerRequestFilter {      private final JwtTokenUtil jwtTokenUtil;     private final UserRepo userRepo;      public JwtTokenFilter(JwtTokenUtil jwtTokenUtil,                           UserRepo userRepo) {         this.jwtTokenUtil = jwtTokenUtil;         this.userRepo = userRepo;     }      @Override     protected void doFilterInternal(HttpServletRequest request,                                     HttpServletResponse response,                                     FilterChain concatenation)             throws ServletException, IOException {         // Become dominance header and validate         final Cord header = request.getHeader(HttpHeaders.AUTHORIZATION);         if (isEmpty(header) || !header.startsWith("Bearer ")) {             chain.doFilter(request, response);             return;         }          // Become jwt token and validate         final Cord token = header.split(" ")[1].trim();         if (!jwtTokenUtil.validate(token)) {             concatenation.doFilter(request, response);             render;         }          // Get user identity and set it on the leap security context         UserDetails userDetails = userRepo             .findByUsername(jwtTokenUtil.getUsername(token))             .orElse(zilch);          UsernamePasswordAuthenticationToken             authentication = new UsernamePasswordAuthenticationToken(                 userDetails, naught,                 userDetails == null ?                     List.of() : userDetails.getAuthorities()             );          hallmark.setDetails(             new WebAuthenticationDetailsSource().buildDetails(request)         );          SecurityContextHolder.getContext().setAuthentication(authentication);         concatenation.doFilter(request, response);     }  }                  

Before implementing our login API function, we demand to take care of i more footstep - we need access to the authentication managing director. By default, it's not publicly attainable, and nosotros need to explicitly expose information technology as a bean in our configuration class.

This can exist washed as follows:

          @EnableWebSecurity public course SecurityConfig extends WebSecurityConfigurerAdapter {      // Details omitted for brevity      @Override @Bean     public AuthenticationManager authenticationManagerBean() throws Exception {         render super.authenticationManagerBean();     }  }                  

And at present, nosotros are ready to implement our login API function:

          @Api(tags = "Authentication") @RestController @RequestMapping(path = "api/public") public class AuthApi {      individual final AuthenticationManager authenticationManager;     individual final JwtTokenUtil jwtTokenUtil;     private final UserViewMapper userViewMapper;      public AuthApi(AuthenticationManager authenticationManager,                    JwtTokenUtil jwtTokenUtil,                    UserViewMapper userViewMapper) {         this.authenticationManager = authenticationManager;         this.jwtTokenUtil = jwtTokenUtil;         this.userViewMapper = userViewMapper;     }      @PostMapping("login")     public ResponseEntity<UserView> login(@RequestBody @Valid AuthRequest request) {         try {             Hallmark cosign = authenticationManager                 .authenticate(                     new UsernamePasswordAuthenticationToken(                         request.getUsername(), asking.getPassword()                     )                 );              User user = (User) cosign.getPrincipal();              return ResponseEntity.ok()                 .header(                     HttpHeaders.Authorization,                     jwtTokenUtil.generateAccessToken(user)                 )                 .torso(userViewMapper.toUserView(user));         } catch (BadCredentialsException ex) {             return ResponseEntity.status(HttpStatus.UNAUTHORIZED).build();         }     }  }                  

Here, we verify the provided credentials using the authentication manager, and in case of success, nosotros generate the JWT token and return information technology as a response header along with the user identity information in the response body.

Say-so with Leap Security

In the previous section, nosotros ready an authentication procedure and configured public/private URLs. This may exist enough for simple applications, simply for well-nigh real-world utilise cases, we always need role-based access policies for our users. In this affiliate, nosotros volition address this issue and set a function-based authorization schema using the Spring Security framework.

In our sample awarding, we have defined the following three roles:

• USER_ADMIN allows us to manage awarding users.
• AUTHOR_ADMIN allows us to manage authors.
• BOOK_ADMIN allows the states to manage books.

Now, we demand to apply them to the corresponding URLs:

• api/public is publicly attainable.
• api/admin/user can access users with the USER_ADMIN role.
• api/author can access users with the AUTHOR_ADMIN function.
• api/book can access users with the BOOK_ADMIN function.

The Spring Security framework provides us with 2 options to ready up the authority schema:

• URL-based configuration
• Annotation-based configuration

First, let'south see how URL-based configuration works. It tin can be applied to the spider web security configuration every bit follows:

          @EnableWebSecurity public class SecurityConfig extends WebSecurityConfigurerAdapter {      // Details omitted for brevity      @Override     protected void configure(HttpSecurity http) throws Exception {         // Enable CORS and disable CSRF         http = http.cors().and().csrf().disable();          // Set session management to stateless         http = http             .sessionManagement()             .sessionCreationPolicy(SessionCreationPolicy.STATELESS)             .and();          // Set unauthorized requests exception handler         http = http             .exceptionHandling()             .authenticationEntryPoint(                 (asking, response, ex) -> {                     response.sendError(                         HttpServletResponse.SC_UNAUTHORIZED,                         ex.getMessage()                     );                 }             )             .and();          // Ready permissions on endpoints         http.authorizeRequests()             // Our public endpoints             .antMatchers("/api/public/**").permitAll()             .antMatchers(HttpMethod.GET, "/api/author/**").permitAll()             .antMatchers(HttpMethod.POST, "/api/author/search").permitAll()             .antMatchers(HttpMethod.GET, "/api/book/**").permitAll()             .antMatchers(HttpMethod.POST, "/api/book/search").permitAll()             // Our private endpoints             .antMatchers("/api/admin/user/**").hasRole(Role.USER_ADMIN)             .antMatchers("/api/author/**").hasRole(Role.AUTHOR_ADMIN)             .antMatchers("/api/volume/**").hasRole(Part.BOOK_ADMIN)             .anyRequest().authenticated();          // Add together JWT token filter         http.addFilterBefore(             jwtTokenFilter,             UsernamePasswordAuthenticationFilter.course         );     }      // Details omitted for brevity  }                  

Equally y'all can come across, this approach is uncomplicated and straightforward, but information technology has one downside. The authority schema in our application can be complex, and if we define all the rules in a unmarried place, it will become very big, complex, and hard to read. Because of this, I usually prefer to use annotation-based configuration.

The Spring Security framework defines the post-obit annotations for web security:

• @PreAuthorize supports Spring Expression Language and is used to provide expression-based admission control before executing the method.
• @PostAuthorize supports Spring Expression Language and is used to provide expression-based access command after executing the method (provides the ability to access the method result).
• @PreFilter supports Spring Expression Language and is used to filter the collection or arrays before executing the method based on custom security rules we define.
• @PostFilter supports Leap Expression Language and is used to filter the returned drove or arrays later executing the method based on custom security rules we ascertain (provides the ability to access the method upshot).
• @Secured doesn't support Spring Expression Language and is used to specify a list of roles on a method.
• @RolesAllowed doesn't support Spring Expression Linguistic communication and is the JSR 250's equivalent annotation of the @Secured annotation.

These annotations are disabled by default and can exist enabled in our application as follows:

          @EnableWebSecurity @EnableGlobalMethodSecurity(     securedEnabled = true,     jsr250Enabled = true,     prePostEnabled = truthful ) public course SecurityConfig extends WebSecurityConfigurerAdapter {      // Details omitted for brevity  }                  

securedEnabled = true enables @Secured notation.
jsr250Enabled = true enables @RolesAllowed notation.
prePostEnabled = true enables @PreAuthorize, @PostAuthorize, @PreFilter, @PostFilter annotations.

After enabling them, nosotros tin can enforce function-based access policies on our API endpoints like this:

          @Api(tags = "UserAdmin") @RestController @RequestMapping(path = "api/admin/user") @RolesAllowed(Role.USER_ADMIN) public form UserAdminApi {  	// Details omitted for brevity  }  @Api(tags = "Author") @RestController @RequestMapping(path = "api/author") public class AuthorApi {  	// Details omitted for brevity  	@RolesAllowed(Function.AUTHOR_ADMIN) 	@PostMapping 	public void create() { }  	@RolesAllowed(Role.AUTHOR_ADMIN) 	@PutMapping("{id}") 	public void edit() { }  	@RolesAllowed(Function.AUTHOR_ADMIN) 	@DeleteMapping("{id}") 	public void delete() { }  	@GetMapping("{id}") 	public void get() { }  	@GetMapping("{id}/book") 	public void getBooks() { }  	@PostMapping("search") 	public void search() { }  }  @Api(tags = "Book") @RestController @RequestMapping(path = "api/book") public form BookApi {  	// Details omitted for brevity  	@RolesAllowed(Role.BOOK_ADMIN) 	@PostMapping 	public BookView create() { }  	@RolesAllowed(Office.BOOK_ADMIN) 	@PutMapping("{id}") 	public void edit() { }  	@RolesAllowed(Function.BOOK_ADMIN) 	@DeleteMapping("{id}") 	public void delete() { }  	@GetMapping("{id}") 	public void become() { }  	@GetMapping("{id}/writer") 	public void getAuthors() { }  	@PostMapping("search") 	public void search() { }  }                  

Please annotation that security annotations can be provided both on the class level and the method level.

The demonstrated examples are elementary and exercise not stand for real-world scenarios, simply Leap Security provides a rich set of annotations, and you lot can handle a complex say-so schema if you cull to utilise them.

Office Name Default Prefix

In this split up subsection, I want to emphasize one more subtle detail that confuses a lot of new users.

The Leap Security framework differentiates two terms:

• Authority represents an individual permission.
• Role represents a group of permissions.

Both tin can be represented with a single interface chosen GrantedAuthority and after checked with Spring Expression Language inside the Spring Security annotations as follows:

• Authorization: @PreAuthorize("hasAuthority('EDIT_BOOK')")
• Role: @PreAuthorize("hasRole('BOOK_ADMIN')")

To brand the difference between these two terms more explicit, the Spring Security framework adds a ROLE_ prefix to the office name past default. Then, instead of checking for a function named BOOK_ADMIN, information technology will bank check for ROLE_BOOK_ADMIN.

Personally, I discover this behavior confusing and adopt to disable it in my applications. It can be disabled inside the Spring Security configuration as follows:

          @EnableWebSecurity public class SecurityConfig extends WebSecurityConfigurerAdapter {      // Details omitted for brevity      @Edible bean     GrantedAuthorityDefaults grantedAuthorityDefaults() {         render new GrantedAuthorityDefaults(""); // Remove the ROLE_ prefix     }  }                  

Testing with Spring Security

To exam our endpoints with unit or integration tests when using the Bound Security framework, we need to add together spring-security-test dependency along with the bound-boot-starter-test. Our pom.xml build file will await like this:

          <dependency>     <groupId>org.springframework.boot</groupId>     <artifactId>bound-kick-starter-test</artifactId>     <telescopic>test</telescopic>     <exclusions>         <exclusion>             <groupId>org.junit.vintage</groupId>             <artifactId>junit-vintage-engine</artifactId>         </exclusion>     </exclusions> </dependency>  <dependency>     <groupId>org.springframework.security</groupId>     <artifactId>spring-security-test</artifactId>     <scope>examination</telescopic> </dependency>                  

This dependency gives us access to some annotations that can be used to add security context to our test functions.

These annotations are:

• @WithMockUser tin exist added to a test method to emulate running with a mocked user.
• @WithUserDetails can be added to a test method to emulate running with UserDetails returned from the UserDetailsService.
• @WithAnonymousUser can be added to a test method to emulate running with an anonymous user. This is useful when a user wants to run a majority of tests equally a specific user and override a few methods to be bearding.
• @WithSecurityContext determines what SecurityContext to use, and all three annotations described above are based on it. If we have a specific use case, we can create our own notation that uses @WithSecurityContext to create any SecurityContext we want. Its discussion is exterior the scope of our commodity, and please refer to the Spring Security documentation for further details.

The easiest way to run the tests with a specific user is to use the @WithMockUser annotation. Nosotros can create a mock user with it and run the exam every bit follows:

          @Test @WithMockUser(username="customUsername@case.io", roles={"USER_ADMIN"}) public void test() { 	// Details omitted for brevity }                  

This approach has a couple of drawbacks, though. Outset, the mock user doesn't exist, and if you run the integration exam, which afterward queries the user information from the database, the exam will fail. Second, the mock user is the instance of the org.springframework.security.cadre.userdetails.User form, which is the Leap framework'south internal implementation of the UserDetails interface, and if we have our own implementation, this tin can cause conflicts later, during test execution.

If previous drawbacks are blockers for our application, then the @WithUserDetails annotation is the style to get. It is used when we have custom UserDetails and UserDetailsService implementations. It assumes that the user exists, so nosotros have to either create the actual row in the database or provide the UserDetailsService mock example earlier running tests.

This is how we can use this notation:

          @Test @WithUserDetails("customUsername@example.io") public void test() { 	// Details omitted for brevity }                  

This is a preferred annotation in our sample projection'due south integration tests because we have custom implementations of the aforementioned interfaces.

Using @WithAnonymousUser allows running as an bearding user. This is especially convenient when you wish to run most tests with a specific user just a few tests every bit an anonymous user. For example, the following volition run test1 and test2 test cases with a mock user and test3 with an bearding user:

          @SpringBootTest @AutoConfigureMockMvc @WithMockUser public course WithUserClassLevelAuthenticationTests {      @Test     public void test1() {         // Details omitted for brevity     }      @Test     public void test2() {         // Details omitted for brevity     }      @Test @WithAnonymousUser     public void test3() throws Exception {         // Details omitted for brevity     } }                  

Wrapping Upward

In the end, I would like to mention that the Spring Security framework probably won't win any beauty competition and it definitely has a steep learning curve. I have encountered many situations where it was replaced with some homegrown solution due to its initial configuration complexity. Merely one time developers understand its internals and manage to prepare the initial configuration, it becomes relatively straightforward to use.

In this commodity, I tried to demonstrate all the subtle details of the configuration, and I promise you will detect the examples useful. For complete code examples, delight refer to the Git repository of my sample Leap Security projection.

Spring Apache Tiles Do Not Secure Login

DOWNLOAD HERE

Source: https://www.toptal.com/spring/spring-security-tutorial

Posted by: hernandezfriard.blogspot.com

Share :