Spring security has been used for our application. Spring security has been configured in bean declaration way.
The problem is : I logged into the application, browsed few pages, and restarted the server(but didn't close the browser). After restarting the server I could successfully move to other pages. I am sure it is not the browser cache as I delete all the cookies before I start go through other pages.
Why does it happen like this ? Is this the default behavior ? How can I enforce the authentication after restarting the server ?
We use Tomcat 6, and it is the default behavior of the tomcat which serializes sessions before server shutdown and de-serializes next time the server is restarted thus it maintains the session.
If we don't want this default behavior then uncomment the 'Manager' element section in the context.xml.
Related
I have a spring boot application (2.1.6) with spring security.
I added a capability of "remember me", but unfortunatelly - after server restart the app doesn't remember the user.
my configuration looks like this:
.and().rememberMe().key("*****").tokenValiditySeconds(15768000)
I debug TokenBasedRememberMeServices , and I saw there is a signature that doesn't much between the cookie and the calculation after restart.
The reason the signatures are different is because they are based on passwords, and the passwords are retrieved differently between setting the remember me cookie and reading the cookie.
I'm not sure why.
All my users are defined in-memory:
authBuilder.inMemoryAuthentication()
.withUser("david")
.password("{noop}mypassword").authorities("ROLE_USER")
Can you please help me understand why the remember me doesn't survive server restarts?
In my application I have an embedded jetty server (version 8.1.2) running a web application that uses spring web security.
The jetty server is configured to use the JDBCSessionManager
One of the security filters that spring employs is a subclass of AbstractAuthenticationProcessingFilter, in it, it has a SessionAuthenticationStrategy which by default is a SessionFixationProtectionStrategy. This protection strategy creates a new session, as a copy of the original session and invalidates the old one.
Now when I try to login to the web application, I see that a new session is created, but the authentication attributes that are added to the new session are not written back to the database. Moreover, I see that the old session is written to the database with new attributes even though it was invalidated.
Finally, when a new http request arrives as part of the new session, it does not pass authentication because of the above.
After some investigation, I found that this behavior does not happen in older versions of jetty (I tried 7.1.4), and I see that the new session data is written to the database.
I could of course solve this issue by any of the following:
Use an older version of jetty
Disable the session fixation protection strategy
Use the default session manager instead of the JDBCSessionManager
But assuming non of the above options are valid for me, I was wondering if there is any solution to this problem.
Thanks!
Resolved in newer releases of jetty 8, at least 8.1.6 :)
I am using the Spring Security Core plugin for my Grails application and I am facing a problem that when I leave my app idle for more than 5-10 minutes, I need to restart the application.
I thought it's a session time out problem so I added a session timeout tag inside my web.xml, but it didn't help.
What else can I try?
Just Check in your application may be you are using
request.getSession().setMaxInactiveInterval(Integer.parseInt(value)*60);
This Line overrides the feature of web.xml Session timeout.
Or
Use this line in your application when you are creating session for user (At login time).
I have an application developed in Grails (v1.3.7) and we used Spring Security Core (v1.2.6) plugin for authentication. After building .war file, I have deployed the application in a standard tomcat server (v7.0.22). The application runs fine.
I know that I can configure Session timeout period in web.xml either before building the application or in the tomcat server itself. But, I want (additionally) to redirect any page to the log-in page automatically whenever the Session is timed out. Because, if the Session times out and users click on any links or simply refresh the current page, they get a tomcat error.
Can anyone suggest a way to resolve it easily? Is there any configuration (like expired-session-url) in Tomcat or Spring Security Core that does the job?
I have search in the plugin doc site, plugin blog site but nothing found. This site suggest that I would require to add a listener in code and I would hate to do that and would like to use a simple configuration like this. Can anyone guide anything?
Thanks in anticipation
Http is stateless protocol, and session is just a marker stored on client cookies (+ local db), and you can't handle this as an event. 'new client' and 'session expired' is the exactly same, it just means that you can't identify browser for current request. For most cases it means also that user is not authenticated (for raw Spring Security Core, at least)
For you case, you already have session expired handler, it's when you're getting this tomcat error. Just handle this error, and redirect user to login page.
Btw, if you have proper Spring Security configuration, it must redirect all non-authorized users to login page. And seems that you have made something wrong with your app architecture, if you have authenticated user, but still having some user datails in standard tomcat session. There at least two ways: avoid your own user session, or make some kind of session-based Spring Security authentication config.
I've got an app built using asp.net mvc and deployed over 2 Amazon EC2 instances. I'm using forms authentication to authenticate users. I simply make a quick look up on the given username and password and if I found a match I set an authentication cookie, like so:
if(_repository.Login(username, password))
FormsAuthentication.SetAuthCookie(username, false);
This works fine as long as the application on one machine, but, once I leveraged Amazon Elastic Load Balancing to deploy the site on two machines, the site behaves in a very weird way. When a user logs in, the site recognizes a logged in user, after a refresh or two, the site no longer see the user as a logged in user. If the user keeps refreshing again for some time, the app sees the user as a logged in user again, and this goes forever.
I'm aware that such a problem might occur if I'm storing SessionState inproc. I'm not using SessionState at all.
What am I missing here guys?
Ps: I've edited the session state to be stored on a state server [Though i'm not using neither sessions nor TempData anywhere on my app] and the same weird behavior is there.
You need to synchronize your <machinekey> between all servers in your farm. Otherwise the forms authentication ticket is only good for the machine which issued it. I doubt this has anything to do with Session/TempData.