It appears the primary behavior of Spring session is to save the session when the HttpResponse is committed.
Does spring-session also support saving the session when "setAttribute" is called on the session ?
If you're using Spring Session with either Redis or Hazelcast session stores, you can set the flush mode to IMMEDIATE (ON_SAVE is the default). This will result in changes to session being persistent to underlying store immediately as they are made.
Take a look at #EnableRedisHttpSession or #EnableHazelcastHttpSession annotations.
Related
I am using Spring Security and I have created a ApplicationListener for HttpSessionDestroyedEvent (for logout and session expiry events). But this listener's onApplicationEvent method is called on login also which looks like a inappropriate behavior. How do I make this working. Below is the code:
public class MySessionDestroyListener implements ApplicationListener<HttpSessionDestroyedEvent> {
#Override
public void onApplicationEvent(HttpSessionDestroyedEvent httpSessionDestroyedEvent) {
httpSessionDestroyedEvent.getSecurityContexts();
// business logic
}
}
You should be prepared to that. The servlet container generally creates a session before the user is connected. When spring-security authenticates the user, it first close that previous session and creates a new one.
That means that an event HttpSessionDestroyedEvent is triggered both on login and logout. You can differentiate those 2 kinks on event by storing for example the user name in session. If it is present, the session was a regular one and it makes sense to call your business logic, if not it was just a technical one and you shoud just ignore it
If your login page uses a HTTP session in a Servlet 3.0 or older container, the Session Fixation Attack Protection will destroy this session and create a new one (migrateSession), see Spring Security Reference:
Session Fixation Attack Protection
Session fixation attacks are a potential risk where it is possible for a malicious attacker to create a session by accessing a site, then persuade another user to log in with the same session (by sending them a link containing the session identifier as a parameter, for example). Spring Security protects against this automatically by creating a new session or otherwise changing the session ID when a user logs in. If you don’t require this protection, or it conflicts with some other requirement, you can control the behavior using the session-fixation-protection attribute on <session-management>, which has four options
none - Don’t do anything. The original session will be retained.
newSession - Create a new "clean" session, without copying the existing session data (Spring Security-related attributes will still be copied).
migrateSession - Create a new session and copy all existing session attributes to the new session. This is the default in Servlet 3.0 or older containers.
changeSessionId - Do not create a new session. Instead, use the session fixation protection provided by the Servlet container (HttpServletRequest#changeSessionId()). This option is only available in Servlet 3.1 (Java EE 7) and newer containers. Specifying it in older containers will result in an exception. This is the default in Servlet 3.1 and newer containers.
When session fixation protection occurs, it results in a SessionFixationProtectionEvent being published in the application context. If you use changeSessionId, this protection will also result in any javax.servlet.http.HttpSessionIdListener s being notified, so use caution if your code listens for both events. See the Session Management chapter for additional information.
There are some solutions for that problem:
don't use session for login page (in most cases not possible)
update to Servlet 3.1 container
change the Session Fixation Attack Protection to none(not recommended)
adopt your business logic
Spring Session uses a different format for its session cookies than Tomcat does. So if you implement Spring Session, even if you would name the session cookie JSESSIONID, all the users have to login again.
This is a point where you potentially lose users, because nobody likes to login. Perhaps this is an edge case, and certainly it's not worth a huge amount of trouble, but I'm curious if it's possible for existing users to use their already stored Tomcat session cookies?
You can implement your own org.springframework.session.web.http.CookieSerializer that matches Tomcat's default cookie serialization and register it as a bean.
Spring Session configuration will then pick it up and use it - see org.springframework.session.config.annotation.web.http.SpringHttpSessionConfiguration#setCookieSerializer for more details.
We are storing user permission information in session object when sign in success. We are reading this session object in every action. When accessing session if session is Null, we do reinitialize the session. We are using MVC 5.
My queries are,
1. Since in every action there may be chances for reinitialize the session(if session is Null). Does this affect application response time?
2. By doing this every request locks the session object. How do avoid session lock?
Thanks,
Kannan Eswar.
I'm coming from PHP background and have a question regarding RoR user sessions. By default PHP uses file storage with write locks for user session data. So it prevents processing of multiple requests by the same client at the same time. How does RoR behaves with sessions?
The default session store in rails store the entirety of the session data in the session cookie itself (known as the cookiestore).
One side effect of this is that if 2 overlapping requests both try and update the session then the last one to send a response back to the client 'wins'.
I don't think any of the session stores commonly in use with Rails have the concurrency property you describe.
how should I store user data in asp.net mvc? Let's say a user want to see 50 records per page. I wanted to save it in Session, but if I am doing it right, the Session resets every time a new controller is initialized. So where? A cookie?
Typically the session is not reset on controller initialization! Make sure you aren't clearing the session from code.
Anyway, storing this in session cause the record-limit to be reset quite often (depend on the session timeout param).
Consider storing this in the user's profile kept in database (will be used after log in), or in cookie (don't require login to be used). This will keep this setting forever - your users will appreciate that :)
Instead of using the built in ProfileProvider-system in ASP.NET, which you should only use i you want to persist user settings across multiple visits, you could instead put a the settingsdata in the session. Maybe wrapped in a serializable object.
Session is cleared if
you clear it in your code
the cookie storing the sessionid expires (depends on your settings i web.config) (if a
cookie expires during a session, it does not truly expire before the user closes all browser windows)
if the application is restarted (unless you use sticky sessions (DB based sessions) in which case sessiondata persists through application restart)
Session does not reset when a new controller is initialized. But it does when you leave the application (your session ends) or the application is restarted. You should use Profile to store this kind of information.
See this:
http://msdn.microsoft.com/en-us/library/2y3fs9xs.aspx
http://www.odetocode.com/articles/440.aspx