So I am trying to determine if this is a bug or browser caching or if I am missing something, but when I log out I can access any page that I have previously accessed before. I even have an ajax call to a rest endpoint and when I call that I print the response and get a 200 ok.
Now if I click logout it returns to the login page with the invalid session url params. So it looks like it is attempting to remove the session, plus if I close the browser fully, not just the tab I can no longer access the pages I was able to access before. But if I don't close the browser I can access any pages that I have already accessed, pages I have not accessed yet forward me to the login page. It makes me wonder if its a browser cache issue, but the 200ok on the ajax request makes me doubt that.
Spring-Security version 3.1.0
Here is my configuration for the logout.
<logout invalidate-session="true" logout-success-url="/login-page.html?logout=true"
logout-url="/j_spring_security_logout" />
<session-management invalid-session-url="/login-page.html?session=invalid">
<concurrency-control max-sessions="1" error-if-maximum-exceeded="true" />
</session-management>
in the web.xml i have added this listener
<listener>
<listener-class>org.springframework.security.web.session.HttpSessionEventPublisher</listener-class>
</listener>
UPDATE
It was indeed a browser cache issue, so to fix it I added to the DispatcherServlet xml
<bean class="org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter">
<property name="cacheSeconds" value="0" />
</bean>
Also added the META tags to head
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Expires" content="-1">
This now disables caching for all my pages and rest methods.
Indeed it really looks like a caching issue:
Try accessing already visited pages with some extra random parameter
...try the same with AJAX call (just append ?random= + Math.random().
Also try POSTing using AJAX, as GET is much more likely being cached.
Finally have a look at Firebug or any other monitoring tool (or access log on the server side) to confirm the request was cached. If caching is the problem, investigate why browser decides to cache your resources.
Related
Could someone help me on this. appreciate your help.
I am using Spring security 3.1 with create-session="stateless" option.
Which throwing "InsufficientAuthenticationException" : "Full authentication is required to access this resource" exception of ExceptionTranslationFilter.
I am not able to understand what I am doing wrong and why I am getting this exception . As this exception stated that the credentials are not proper but I can see the credentials are going through request.Still I am getting 401 unauthorized
Fact is that the user is able to login properly & I get the message on console also. But again it is redirecting to login page due to access denied exception.
Here I am putting the code
Spring-Security.xml
<http entry-point-ref="negotiateSecurityFilterEntryPoint"
create-session="stateless" >
<intercept-url pattern="/user/loginuser" access="ROLE_ANONYMOUS"/>
<intercept-url pattern="/**" access="ROLE_USER"/>
<custom-filter ref="securityContextPersistenceFilter" after="BASIC_AUTH_FILTER" />
<custom-filter ref="ldapAuthFilter" position="CAS_FILTER" />
<custom-filter ref="databaseAuthFilter" position="FORM_LOGIN_FILTER" />
</http>
<bean id="securityContextPersistenceFilter" class="org.springframework.security.web.context.SecurityContextPersistenceFilter">
<property name='securityContextRepository'>
<bean class='org.springframework.security.web.context.HttpSessionSecurityContextRepository'>
<property name='allowSessionCreation' value='false' />
</bean>
</property>
</bean>
As far as I know, that's exactly what stateless is meant to do.
Once you set create-session parameter as stateless, on every http call the SecurityContextPersistenceFilter won't be even called (by default) or, even if you force it to be called according to your configuration, it won't be any session level security information in the SecurityContextHolder.
This stateless pattern is intended to be used in a Rest style architecture, where authentication and authorization information is sent on every request. Better said, I don't think that stateless session creation pattern should be used unless you are developing a full stateless application
I found a good post about this, Spring Security Session Management, look carefully section 2. When Is The Session Created?
So stateless session creation strategy does not fit to a classic login form pattern.
In your scenario, I guesss that what is happening is that, once the login request is completed and the request is authenticathed, it is probably redirecting to a kind of welcome page using an HTTP 301 or 302 redirect, redirection which again is not carrying authentication info, so ends redirecting again to login page.
If you simply use "ifRequired" as session-creation, or as it is the default value, just don't set it, I bet your login would end successfully and redirect to wherever it should correctly without asking to log in again. And, if you do it like this, avoid setting the SecurityContextPersistenceFilter, it is configured automatically.
I've seen this a few times in our logs and users have also reported it to us but have never really gotten to the bottom of the problem.
From time to time, a page will render from output caching with links that have a strange path value in. Say (X(3)S(5l53uwuaffkddojv4iwb3snm)). Presumably this occurs because the first render of the page has these links, and they are therefore cached with them.
This means that all urls on that page look similar to this.
http://www.example.com/(X(3)S(5l53uwuaffkddojv4iwb3snm))/foo/bar/index.htm
This looks identical to this question and the MSDN article "Understand How the ASP.NET Cookieless Feature Works", except that we use sessions or session cookies for our public site, but for 99% of our site, we don't actually use sessions. The remaining 1% uses session cookies for the user experience, so I don't see how this causes a problem with the rest of our site.
This part of the above article seems to reference the issue:
// Step 2: Check if we have already detected that Cookies are not
// supported. This is detected by looking for the string
// "/(X(1))/" in the URL
If (URL-contains-"/(X(1))/")
Report_cookies_are_NOT_supported_and_exit;
Currently the sessionstate looks like this:
<sessionState mode="SQLServer" sqlConnectionString="data source=myDatabase;user id=dbUsername;password=dbPassword" cookieless="false" timeout="10080" />
Anyone have any ideas on how I can resolve this issue? Is there a way we can prevent urls like this from displaying?
Make sure you have forced the usage of cookies:
<sessionState cookieless="UseCookies" />
and for the forms authentication cookie as well:
<forms loginUrl="~/Account/LogOn" timeout="2880" cookieless="UseCookies" />
If you don't do that and have a client browser which has cookies disabled you will get the aforementioned token in the url.
I have an ASP.NET 4 site with url's having session string embedded in them. Due to this Google index the same page multiple times, all with different session id's. This is affecting my ranking. Earlier i also had the aspautodetectcookie string appended to the url. But i was able to remove it, however the session id embedded in the url remains a problem still.
If my url is http://www.somesite.com/ViewProduct.aspx?ID=12, it shows up like this http://www.somesite.com/S(yya4h4rf4gjh5eo4uazix2t055)X(1))/ViewProduct.aspx?ID=12. I want it to show like http://www.somesite.com/ViewProduct.aspx?ID=12 all the time.
Here are some settings in my web.config that may help you help me
<authentication mode="Forms">
<forms cookieless="UseCookies" loginUrl="~/AccessDenied.aspx" name="FORMAUTH" />
</authentication>
<sessionState mode="InProc" cookieless="false" timeout="15" />
<anonymousIdentification cookieless="AutoDetect" enabled="false" />
Now one user asked to change cookieless="true" to fix the problem. However in the artcle http://www.beansoftware.com/ASP.NET-Tutorials/Cookieless-Session-State.aspx the guy says that by adding cookieless = "true" session id 'will be' embedded in all page URLs.
Can anyone tell me how remove this session from the url - forever.
I am running on IIS 7 but do not have much access to the admin features.
If you set cookieless="false" that will solve the problem you are seeing with Google.
However this means that any browser, which doesn't support cookies, will get a new session per request. If you want more help, please tell us how you are using the sessions.
I am newbie in Spring Security 3, and I am having the next problem.
Using the spring-security Namespace, I try to configure a single basic authentication, in wich I want only to filter the POST method.
From my servlet.xml configuration:
<security:http auto-config='true'>
<security:http-basic></security:http-basic>
<security:intercept-url method="POST" pattern="/**" access="ROLE_USER" />
</security:http>
Well, the thing is that, after starting the server, it works fine the first time (that is, the other methods doesn't prompt any authentication screen). But after a first use of the POST method, it prompt the authentication screen for all the method. Does anyone knows what am I missing?
Thanks in advance for your time! ;-)
Ok, auto-answer! xD
I was using to try it a Firefox plugin called Rest Client (I really recommend it ;-) ). My failure was, after the first login tryial with the POST method, that it saved in cache that it has prompted an HTTP-BASIC authentication. After cleaning my history, it works fine.
After that, I have learned:
-Think always in the cache when you use a browser
-Give more information about your environment when you ask something in Stackoverflow xD
Thanks everyone!!
I have a problem with my j2ee application using spring security. I set max-sessions in concurrent-session-control to 1. Now it works fine when I try to Login the second time it will stop me. But when I logout the other one and try to login again I still get this same message.
Your login attempt was not successful, try again.
Reason: Maximum sessions of 1 for this principal exceeded
I have this in my http security
<security:logout logout-url="/logout.do"
invalidate-session="true" logout-success-url="/logoutSuccess.do" />
<security:concurrent-session-control
max-sessions="1" exception-if-maximum-exceeded="true" expired-url="/loginform.do" />
It's been quite a while since you posted this, but if anyone else is having this problem I believe this behavior will occur if you don't add org.springframework.security.web.session.HttpSessionEventPublisher as a listener in your web.xml.
See here:
Adding the listener to web.xml causes an ApplicationEvent to be published to the Spring ApplicationContext every time a HttpSession commences or terminates. This is critical, as it allows the SessionRegistryImpl to be notified when a session ends. Without it, a user will never be able to log back in again once they have exceeded their session allowance, even if they log out of another session or it times out.
please check that the error page is not cached (press F5) and look in the logs to see if the logout is working fine.
Make sure your Spring Security Filters run before your Struts Filter.
Set a break point at Spring Security's LogoutFilter.doFilterHttp method. Make sure that part runs properly.