Hello guys, one of the frequently asked Spring Security Question is about the order of multiple intercept-urls in Spring security configuration file e.g. applicationContext-security.xml. If you have to define more than one intercept URLS, which order will you define them? Does order or URLs in configuration file even matters? The short answer of this question is, Yes, ordering of intercept URLs in Spring Security configuration file does matter and if you have to define multiple intercept-urls then you define the in a order from most specific to least specific. Why you should that? because Spring security tries to match the URL of every incoming request or outgoing response to the intercept urls in the same order they are declared.
So if you declare the least specific URL first then most of the request will match that URL pattern and your more specific pattern will never execute.
When you declare them in the order from most specific to generic, Spring security first tries to match the incoming request with most specific intercept URL and only when it doesn't succeed, it tries the next, less specific one.
This way you can implement different kind of security arrangement e.g. allowing access to only specific URLS and denying then all others. This is known as the maintaining a whitelist of URLs and it's a common technique for access restriction on application.
How to define multiple intercept-URL in Spring Security?
Let' see an example to understand the concept better, here is the list of intercept URLs from a Spring security configuration file
<intercept-url pattern="/static/**" filters="none" />
<intercept-url pattern="/login.jsp*" filters="none" />
<intercept-url pattern="/logout.jsp*" filters="none" />
<intercept-url pattern="/forgotpassword*" filters="none" />
<intercept-url pattern="/WEB-INF/jsp/forgotpassword*" filters="none" />
<intercept-url pattern="/**/trade*" access="hasRole('ROLE_VIEW_TRADER')" />
<intercept-url pattern="/**/admin*" access="hasRole('ROLE_VIEW_OPERATION')" />
<intercept-url pattern="/**/shop*"
access="hasRole('ROLE_INTERNAL') and hasRole('ROLE_CREATE_SALES_ORDER')" />
<intercept-url pattern="/**" access="hasAnyRole('ROLE_INTERNAL','ROLE_EXTERNAL')" />
In Spring Security, intercept-url patterns are specified as regular expression, which means you can define spring security intercept-url patterns using wildcards to control access to more than one URL. For example, /** will match to any URL.
Let's say a request for login.jsp comes in, since we have declared login.jsp pattern in the URL above the generic URL pattern "/**" it will first evaluate the login.jsp pattern "/login.jsp*" and since no filter is applied on that, it will provide insecured access to the client. It will not evaluate any more pattern and all intercept-url patterns coming after it will be ignored.
And, if you are not aware how spring security works, here is a nice diagram which explains Spring Security URL interception
Since intercept-url patterns are always evaluated in the order they are defined. It is important that more specific patterns are defined higher in the list than less specific patterns. This is reflected in our example above, where the more specific "/**/trade*" pattern appears higher than the less specific "/**" .
If they were reversed, the "/**" pattern would always match and the "/**/trade*" pattern would never be evaluated.
Sometime it's not obvious that which intercept-url pattern is more obvious for example between
<intercept-url pattern="/api/v1/messages" method="GET" access="permitAll()" /> is more specific than <intercept-url pattern="/api/v1/messages/**" access="hasRole('...')" /> but may not be obvious to many developers.
In general, A pattern with a lower count of URI variables and wildcards is considered more specific. For example /books/{book}/* has 1 URI variable and 1 wild card and is considered more specific than /books/{book}/** which as 1 URI variable and 2 wild cards.
That's all about ordering of multiple intercept-url patterns in Spring security configuration file. Spring security intercept url patterns are evaluated in the order they are listed in the file and as soon as a match is found, rest of the patterns are ignored.
This is why you should define the more specific intercept-url pattern earlier in the order and lest specific patterns later. If you want to learn more about Spring Security, I suggest you to join Eugen Paraschiv's Spring Security Master class. Eugen has rich experience on securing Java application using Spring and you benefit from his practical experience and knowledge by joining this class.
Other Spring Articles you may like
- How to enable Spring Security in Java Application?
- Top 5 Courses to become a full-stack Java developer
- 10 best Spring Framework courses for Java developers
- What is the use of DispatcherServlet in Spring MVC?
- 10 Advanced Spring Boot Courses for Java programmers
- 5 Books to Learn Spring MVC Framework
- How Spring MVC Framework works internally?
- Spring MVC Interview Questions
- 10 Free Courses to learn Spring Framework
- 10 Free Courses to learn Spring Boot for Java programmers
- 10 Courses to learn Microservices in Java
- 10 Advanced Spring Security OAuth2 and JWT courses
- How to control the number of active sessions for a User?
- 25 Spring Security Interview Questions with Answers
Thanks for reading this article, If you like this spring security interview question about multiple intercept URLs in configuration file and my answer and explanation then please share them with your
friends and colleagues. If you have any questions or feedback then
please drop a comment.
P. S. - If you are new to the Spring framework and looking for a comprehensive course to learn the Spring framework then I also suggest you to checkout this list of best Spring Security online courses. It contains the most up-to-date course to learn Spring Security, OAuth2.0, and JWT in depth.
P. S. - If you are new to the Spring framework and looking for a comprehensive course to learn the Spring framework then I also suggest you to checkout this list of best Spring Security online courses. It contains the most up-to-date course to learn Spring Security, OAuth2.0, and JWT in depth.
No comments:
Post a Comment