Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SEC-1171: Allow multiple namespace <http> elements to support multiple filter chain configurations #1419

Closed
spring-projects-issues opened this issue May 31, 2009 · 11 comments
Labels
in: config An issue in spring-security-config type: enhancement A general enhancement type: jira An issue that was migrated from JIRA
Milestone

Comments

@spring-projects-issues
Copy link

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.

@spring-projects-issues
Copy link
Author

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.

@spring-projects-issues
Copy link
Author

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.

@spring-projects-issues
Copy link
Author

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.

@spring-projects-issues
Copy link
Author

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.

@spring-projects-issues
Copy link
Author

TimP said:

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

@spring-projects-issues
Copy link
Author

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.

@spring-projects-issues
Copy link
Author

Luke Taylor said:

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 :).

@spring-projects-issues
Copy link
Author

Luke Taylor said:

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.

@spring-projects-issues
Copy link
Author

Kuntal Mondal said:

Hi Luke,
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?

org.springframework.aop-3.0.3.RELEASE.jar
org.springframework.asm-3.0.3.RELEASE.jar
org.springframework.beans-3.0.3.RELEASE.jar
org.springframework.context-3.0.3.RELEASE.jar
org.springframework.core-3.0.3.RELEASE.jar
org.springframework.expression-3.0.3.RELEASE.jar
org.springframework.jdbc-3.0.3.RELEASE.jar
org.springframework.ldap-1.3.0.RELEASE.jar
org.springframework.web-3.0.3.RELEASE.jar
org.springframework.web.servlet-3.0.3.RELEASE.jar
spring-security-config-3.1.0.M1.jar
spring-security-core-3.1.0.M1.jar
spring-security-ldap-3.1.0.M1.jar
spring-security-taglibs-3.1.0.M1.jar
spring-security-web-3.1.0.M1.jar
spring-tx-3.0.3.RELEASE.jar

Thanks a lot,

  • Kuntal

@spring-projects-issues
Copy link
Author

Luke Taylor said:

The syntax is explained in the reference manual. If you have problems, please post your questions in the forum rather than the issue tracker.

@spring-projects-issues spring-projects-issues added Namespace type: jira An issue that was migrated from JIRA labels Feb 5, 2016
@spring-projects-issues spring-projects-issues added this to the 3.1.0.M1 milestone Feb 5, 2016
@spring-projects-issues
Copy link
Author

This issue supersedes #1712

@rwinch rwinch added in: config An issue in spring-security-config type: enhancement A general enhancement labels May 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: config An issue in spring-security-config type: enhancement A general enhancement type: jira An issue that was migrated from JIRA
Projects
None yet
Development

No branches or pull requests

2 participants