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-866: We should be able to change the course after successfulAuthentication #1121

Closed
spring-projects-issues opened this issue Jun 4, 2008 · 2 comments
Labels
in: core An issue in spring-security-core status: declined A suggestion or change that we don't feel we should currently apply type: enhancement A general enhancement type: jira An issue that was migrated from JIRA
Milestone

Comments

@spring-projects-issues
Copy link

spring-projects-issues commented Jun 4, 2008

from SEC-866) said:

The onSuccessfulAuthentication() call in AbstractProcessingFilter is incapable of changing the course of sendRedirect that follows redirecting to the previosly determinedTargetURL.

so the Flow is always

determineTargetUrl
onSuccessfulAuthentication
..
sendRedirect

Since onSuccessfulAuthentication is extended by custom logic, it may be possible that this logic may want to rediect the response to a different url.
A response.sendRedirect() in the onSuccessfulAuthentication() implementation would cause a failure in the subsequent sendRedirect.

A Sample Use Case can be:
1. attemptAuth() succeeds
2. successfulAuthentication called
3. onSuccessfulAuthentication in 2 calls a userLogic()
4. userLogic builds some other data – some data couldnot be built – fatal/error/warn – send to a different page.
5. but sendRedirect called after 4 completes – Throughs IlleagalStateException as response already redirected.

Is there an existing solution to this?

@spring-projects-issues
Copy link
Author

spring-projects-issues commented Jun 4, 2008

Luke Taylor said:

The intended flow is as you describe and caters for the vast majority of use cases. You can always override the successfulAuthentication method itself if you need to do something that doesn’t fit the current template.

@spring-projects-issues
Copy link
Author

spring-projects-issues commented Jun 5, 2008

Sarath said:

There is a lot of Spring code in successfulAuthentication(). This weight lifting should not be delegated to the developer who doenot need to know it.

The main reason why a onSuccessfulAuthentication() call back is provided is for the same reason. The developer will do only the user logic, not the spring logic. It is just that there is no control on the response.

In a similar issue, instead of overriding successfulAuthentication(), I threw a user defined Exception and wrote an exception page in web.xml. It is fine by me. But I thought this is more frequently applied use case. having a flag to return to control the response would definitely be a plus.

@spring-projects-issues spring-projects-issues added in: core An issue in spring-security-core Closed type: enhancement A general enhancement status: declined A suggestion or change that we don't feel we should currently apply type: jira An issue that was migrated from JIRA labels Feb 5, 2016
@spring-projects-issues spring-projects-issues added this to the 2.0.3 milestone Feb 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core An issue in spring-security-core status: declined A suggestion or change that we don't feel we should currently apply type: enhancement A general enhancement type: jira An issue that was migrated from JIRA
Projects
None yet
Development

No branches or pull requests

1 participant