Luke Taylor (Migrated from SEC-1171) said:
The main use case for this is supporting stateless and stateful URLs within the same application (different session creation policies). For example, a normal application which users can log into may also expose REST service endpoints.
Alex Marshall said:
One specific use case for this feature is having a RESTful webservice that you want to use HTTP BASIC authentication along one path of URLs, and using form authentication for the rest of your URLs.
Markus Wolf said:
Another use case is providing atom/rss feeds at specified urls which should be secured.
There are many feed readers which could not authenticate with such urls since they get a redirect to the login-form.
Luke Taylor said:
An alternative option (more feasible in 3.0, since we have reduced the use of global beans) would be to permit the use of more than one block, and assemble a single FilterChainProxy from the results. This would require some careful consideration though.
Caoilte O'Connor said:
We have a checkout flow which has very slightly different properties to the standard flow and requires its own EndPoint (differnt login pages and messaging controls) and authentication filter (different redirects on success and failure)
This was all possible with Spring Security 2.0 but is difficult with 3.0 name space configuration (which seems a lot lot less flexible). I have a hacky work around and I could fall back to a FilterChainProxy but it would be nice to have a clean implementation for what must be a very common business requirement.
This may not be relevant, but I got misled by this bug so want to mention that you can support http-basic authentication and forms authentication for the same url.
If basic authentication is present it will be honoured, you will not be redirected to a form login.
wget relies upon a challenge before supplying authentication, so wget will get redirected unless you use the --auth-no-challenge qualifier
Jamie Cramb said:
Another use case for this is if you have multiple "channels" (mobile site, desktop site, admin portal, etc) ; without being able to have multiple http elements you can't configure a channel-specific login pages, access denied pages, etc.
I've been able to work around this before by using a single http element with additional login/logout handlers and a custom ExceptionTranslationFilter that can invoke the correct AuthenticationEntryPoint / AccessDeniedHandler based on URL patterns but this would make it much cleaner.
Most of the work for this issue is already in the trunk (see the source tab), so feel free to try it out.
Please keep the comments specific to the work on the issue and how the feature is implemented. We all know there are plenty of use cases :).
Complete based on current design. There may be some scope for syntax changes later but these will be raised as separate issues.
One side-effect of this issue is that the use of the filters='none' attribute on an element is no longer supported. Patterns which should bypass security should use a separate, childless, element with the required pattern and the attribute security='none' instead. The docs and examples have been updated to use the new sytax.
Kuntal Mondal said:
I am still getting the same problem with 3.1.0-M1 release.
Can you pls. let me know what changes I need to do?
My declarations are as shown above.
In my WEB-INF/lib directory I have following Spring jars.
Am I missing any thing there?
Thanks a lot,
The syntax is explained in the reference manual. If you have problems, please post your questions in the forum rather than the issue tracker.
This issue supersedes #1712