I have a form login entry point currently defined like so:
<form-login login-page="/spring/login"
login-processing-url="/spring/login"
authentication-failure-url="/spring/loginfail"
default-target-url="/spring/loginsuccess"
always-use-default-target="true" />
This works just fine but I want to convert it into a custom authentication entry point. I have a class that extends LoginUrlAuthenticationEntryPoint which gets called when authentication is needed.
My question is: How do I support POSTing the username/password using this pattern?
When I remove the form-login block I get a POST not supported error. I guess since I can no longer define the login-processing-url, where do I post the credentials so that Spring Security can perform the authentication?
I think I figured this out. I misunderstood how this works. The form-login AuthenticationEntryPoint should be a singular entry point in the application. The AuthenticationEntryPoints mapped to other patterns should simply re-direct to the URL which is mapped to the entry point containing the form-login entry point IF form-login is required, otherwise we could handle this differently.
Related
In my application, after a user is logged in, every time he sends a request (get/post), before calling the method in controller, i want to verify the session attribute set in the request (i set a session attribute during his login). I see that this can be implemented through spring interceptors (OR) spring AOP. which one should i use?. I have a feeling interceptors are outdated. Or is there a way in spring security which does this for me?
So you want this intercept to happen only for all the controller methods ..? Does the controller have Base URL that its getting invoked for (post/get/delete)...? Is it more like you want to intercept the http request for a particualt URL ..? like this one
<intercept-url pattern="/styles/**" filters=" .." />
If your use case is boiled down to a particular URL pattern then you can write a custom filter extending GenericFilterBean and you can plug it to the filters attribute.So this will get called for every request matching url pattern and in your custom filter you can do whatever you wanted to do.
What if you try implementing a simple Filter? You can extend already existing Spring filter, or create your own by implementing javax.servlet.Filter
The spring security way seems the best way to me with access to specific roles also can be assigned. very good example given in http://www.mkyong.com/spring-security/spring-security-form-login-using-database/
I'm using spring 3.1.1 and spring security 3.1.0. I'd like to enforce a policy that all http requests that are not explicitly configured with an <intercept-url pattern="..." access="..."/> entry are handled in a particular way. For requests that match a configured <intercept-url/> I want to use typical role based access decisions. However, for non-matching requests, I want to either respond with a 404 (not found) (or maybe 403/forbidden). I want to do this so that I and other team members are forced to explicitly configure spring security and associated roles for any new endpoints.
I originally thought that I could use <intercept-url pattern="/**" access="denyAll"/> as the last intercept-url and that spring would do what I wanted. This technique works if the user is already authenticated but is a little strange for unauthenticated/anonymous users. For anonymous users, spring detects (in ExceptionTranslationFilter) that the user is anonymous and starts the authentication process when requests like /missingResource are processed. Typically this means that the user is redirected to a login form and, after logging in, is redirected back to /missingResource. So the user has to login in order to see a 404 (not found) page.
I ended up removing the intercept-url pattern="/**" access="denyAll"/> and writing a custom filter that runs after="FILTER_SECURITY_INTERCEPTOR" and responds with 404 for requests that are not matched by the FilterSecurityInterceptor but it seemed a little complicated. Is there a better or simpler way?
you can define a separate http element for intercept url /** with access ="denyAll" and add a custom entry-point-ref to avoid spring to redirect user to login form, you can use existing entryPoint Http403ForbiddenEntryPoint for showing 403 error response or implement your own by implementing AuthenticationEntryPoint.
Hope it helps.
We are using Spring Security for managing authentication. The issue we are seeing is that when a user's session is timed out between bringing up a GET form and hitting the save button that does a POST, they are sent to the login page but spring is saving the original post information in the session.
Our app does not bring them back to the original URL after login, but instead sends them back to a common starting page. This works fine, but when the user happens to return to the page they had originally tried to POST to (the form GET and POST are the same URLs) Spring tries to resubmit the POST automatically which is not what we want.
Is there a way to completely disable the SavedRequest storing logic in Spring?
I guess this jira issue of spring security describes your problem and how to handle this.
Based on Nathan's comment on Raghuram's answer, with namespaced XML it's something like this:
<security:http>
<security:request-cache ref="nullRequestCache" />
<!-- ... -->
</security:http>
<bean id="nullRequestCache" class="org.springframework.security.web.savedrequest.NullRequestCache" />
There are two scenarios:
1) If you want that after relogin, user should always get forwarded to the default target URL instead of the orginal requested URL then put always-use-default-target="true" in your security.xml like
<http auto-config="true">
.....
<form-login login-page="/login" always-use-default-target="true" default-target-url="/xyz"
authentication-failure-url="/login?error=true" login-processing-url="/j_security_check"/>
</http>
1) If you want that on session timeout after relogin, user should forward to the orginal requested URL but you do not want to resubmit the form then put session-fixation-protection="newSession" in your security.xml like
<http auto-config="true">
<session-management session-fixation-protection="newSession"/>
.....
</http>
Please put session-management tag as first line in http configuration.
It looks like the session-fixation-protection="newSession" attribute on (2.0) or (3.0) will also resolve the issue
With Spring 4.2.5 I ran into this too.
My case was almost identical: display GET form, wait for session timeout, then POST the form. In my app after re-authentication a start page is displayed. However, if the user then navigates to this GET form, and POSTs it, then the previous POST parameters are remembered and concatenated to the current request, resulting in comma separated values in the #RequestParam variables.
I dumped the session in my authentication controller and indeed I saw a "SPRING_SECURITY_SAVED_REQUEST" named key.
The spring documentation says that by default a "SavedRequestAwareAuthenticationSuccessHandler" is used for retrieving the saved request data from the session and apply it to the request.
I tried to use a do-nothing successHandler but couldn't make it work.
I also tried applying
http.sessionManagement().sessionFixation().newSession();
to the security config but that didn't help.
However
http.requestCache().requestCache(new NullRequestCache());
solved the issue.
I would like to add captcha to spring security form, how can I implement this?
I have declared my custom form login like: <form-login login-page="/login" /> now I need to override authentication filter to verify captcha, how to do it?
#misha, take a look at this article: Spring Security 3: Integrating reCAPTCHA Service.
This uses two filters to make reCAPTCHA integration as seamless and unobstrusive as possible. That means your existing Spring Security implementation will not break. No need to touch existing classes.
There's no need to override your existing implementation. You can add CAPTCHA to your existing implementation.
I guess you can override attemptAuthentication method as following (pseudo code):
1. get captcha response
2. verify captcha response
3. if invalid response, throw some kind of AuthenticationException (may be named as CaptchaFailedException) that you can check in your custom AuthenticationFailureHandler
4. if valid response, call super.attemptAuthentication(request,response)
1) How can i add a custom field in my login form and use that value to navigate to a different page after login. I need a custom authentication provider for authenticating. Can we use spring mvc to tie all this?
2) How can we get hold of HttpSession in auth provider?
1) I guess, you can choose the default behavior by implementing your own AuthenticationSuccessHandler and passing it to <form-login authentication-success-handler-ref="..."/>
2) This is actually not in the vein of the separation of concerns paradigm in Spring Security where the authentication provider populates the Authentication object and another filter persists/populate the authentication in/from the HTTP session. Nevertheless, you can in general have access to the current HTTP request and, therefore a session, from anywhere inside the request processing chain by adding the filter org.springframework.web.context.request.RequestContextListener to your web.xml. Use then ((ServletRequestAttributes) RequestContextHolder.getRequestAttributes()).getRequest().getSession() to reach the session from your authentication provider.