If you're working on a Spring Security (and especially an OAuth) implementation, definitely have a look at the Learn Spring Security course:
>> LEARN SPRING SECURITYMocking is an essential part of unit testing, and the Mockito library makes it easy to write clean and intuitive unit tests for your Java code.
Get started with mocking and improve your application tests using our Mockito guide:
Handling concurrency in an application can be a tricky process with many potential pitfalls. A solid grasp of the fundamentals will go a long way to help minimize these issues.
Get started with understanding multi-threaded applications with our Java Concurrency guide:
Spring 5 added support for reactive programming with the Spring WebFlux module, which has been improved upon ever since. Get started with the Reactor project basics and reactive programming in Spring Boot:
Since its introduction in Java 8, the Stream API has become a staple of Java development. The basic operations like iterating, filtering, mapping sequences of elements are deceptively simple to use.
But these can also be overused and fall into some common pitfalls.
To get a better understanding on how Streams work and how to combine them with other language features, check out our guide to Java Streams:
Get started with Spring and Spring Boot, through the Learn Spring course:
>> LEARN SPRINGExplore Spring Boot 3 and Spring 6 in-depth through building a full REST API with the framework:
Yes, Spring Security can be complex, from the more advanced functionality within the Core to the deep OAuth support in the framework.
I built the security material as two full courses - Core and OAuth, to get practical with these more complex scenarios. We explore when and how to use each feature and code through it on the backing project.
You can explore the course here:
Spring Data JPA is a great way to handle the complexity of JPA with the powerful simplicity of Spring Boot.
Get started with Spring Data JPA through the guided reference course:
Refactor Java code safely β and automatically β with OpenRewrite.
Refactoring big codebases by hand is slow, risky, and easy to put off. Thatβs where OpenRewrite comes in. The open-source framework for large-scale, automated code transformations helps teams modernize safely and consistently.
Each month, the creators and maintainers of OpenRewrite at Moderne run live, hands-on training sessions β one for newcomers and one for experienced users. Youβll see how recipes work, how to apply them across projects, and how to modernize code with confidence.
Join the next session, bring your questions, and learn how to automate the kind of work that usually eats your sprint time.
1. Overview
Spring Security provides multiple mechanisms to configure request patterns as unsecured or to allow unrestricted access. In this article, weβll explore two commonly used approaches: permitAll() and web.ignoring() and how they work within Spring Security.
Further reading:
Spring Security - Roles and Privileges
2. Configuring Access With permitAll()
Configuring permitAll() allows all requests on the specified path without disabling the security filters. This ensures that Spring Security-related functionality, such as logging, session management, and CSRF protection, remains active.
Using Java configuration, we can enable access to the /login* path:
http.authorizeHttpRequests(authorizationManagerRequestMatcherRegistry ->
authorizationManagerRequestMatcherRegistry
.requestMatchers("/login*").permitAll()
);
This configuration ensures that the /login* path is accessible to everyone while keeping the security filters active. Itβs particularly useful for login pages, where some Spring Security features, such as CSRF tokens, are required.
3. Disabling Security Filters With web.ignoring()
In Java configuration, we can exclude the security filter chain for specific paths, such as static resources:
web.ignoring().antMatchers("/resources/**");
This approach is useful for paths where no security processing is needed, such as serving static assets like images, CSS, and JavaScript files. However, itβs important to note that Spring Security features, such as logging or CSRF tokens, wonβt be available for these paths.
4. Caveats for web.ignoring()
When using configurations like web.ignoring(), the order of definition matters. Specific paths must be defined before universal match patterns like β/**β.
More specific patterns should be defined before more general ones to ensure proper matching. If the universal pattern β/**β is defined before other patterns, it overrides them, causing the application to fail with an error:
Caused by: java.lang.IllegalArgumentException: A universal match pattern ('/**')
is defined before other patterns in the filter chain, causing them to be ignored.
Please check the ordering in your <security:http> namespace or FilterChainProxy bean configuration
at o.s.s.c.h.DefaultFilterChainValidator.checkPathOrder(DefaultFilterChainValidator.java:49)
at o.s.s.c.h.DefaultFilterChainValidator.validate(DefaultFilterChainValidator.java:39)
5. Conclusion
In this tutorial, we discussed the options for allowing access to a path using Spring Security. We explored the key differences between permitAll() and web.ignoring(), highlighting their use cases and scenarios where each approach is most suitable.
