I am trying to switch my http session to redis in my spring boot application.
When the first request comes to backend it's being filtered by authentication filter.
One duty of this filter is to populate user session bean with data. The session is succesfully saved to the redis instance at this step, but the delta of changes ( which should include the session bean) is not invoked. I want to point out that with storing session on tomcat the session beans work correctly.
So why session bean populated on OnePerRequest filter is not updated as the delta of session ?
Have you tried the below configuration?
#Configuration
#EnableRedisHttpSession(saveMode = SaveMode.ALWAYS)
public class RedisSessionConfig {
}
Try changing the flush mode to IMMEDIATE, by default it's ON_SAVE which means you explicitly have to save the session or in a managed environment, it happens before the response is serialized (I think).
In src/main/resources/application.properties you could do:
spring.session.redis.flush-mode=immediate
Or using #EnableRedisHttpSession do:
#EnableRedisHttpSession(redisFlushMode = RedisFlushMode.IMMEDIATE)
Related
I have a spring boot project which uses webflux and spring session with redis (cluster mode) for session management.
I am trying to change the session ID when user state changes using
webSession.changeSessionId()
This results in a crossslot keys in request don't hash to the same slot error from redis.
How to overcome this issue?
Everything obviously works fine with local standalone redis.
Code to change session ID:
return Mono.justOrEmpty(sessionObj).flatMap(n -> {
sessionObj.set... // some change in values
setSessionAttribute(webSession, servicesSession);
return webSession.changeSessionId();
});
I am working on a weam web application where the once the user logs in, the main (or landing) page calls 4 stateful session beans. So once the user logs in, there will be atleast 4 threads of stateful session beans created. The page also has a logout button. The logout component in the xhtml calls a POJO which has a logout method.
In the logout method, the following statement is executed:
Session.instance().invalidate();
Now the question is, will the 4 threads/instances of the stateful session beans which are created when the user logs in will be destroyed or not.
I am running this application on JBOSS 4.2.3, Seam 2.2.1 Final
I am using JOSSO for authentication.
Yes, they're all part of the same session. You're actually creating session scoped beans, not separate sessions.
Easy enough to check though. Create a method in each of the session beans and annotate them with #Destroy, when the annotated bean is destroyed, it will call this method.
#Destroy
public void callMeWhenIDie(){
log.debug("I'm melting, I'm melting" + this.someDefiningCharacteristic);
}
I'm using Spring 3.1.1.Release, Security 3.1.0.Release.
I've added login/logout to my web app, however a session scoped bean is not functioning the way it was. The bean is used to connect to a CMS called CMSConnector.
To authenticate users, I implemented an AuthenticationProvider, and in the authenticate() call, I get the session-scoped CMSConnector and call the CMSConnector.login(). If the CMS login fails, it fails the login.
THE PROBLEM -
If the login is success, #predestroy logout() is called immediately after the successful login. I then found it was the SessionFixationProtectionStrategy is invoking the invalidate the previous session and assign it a new session.
session.invalidate();
session = request.getSession(true); // we now have a new session
The invalidate() is calling the #predestroy method on the session-scoped bean.
So I have temporarily removed the the #predestroy annotation leaving the connection not closed. (VERY BAD PRACTICE.)
What is a work around to resolve the issue?
I tried to create a #PostConstruct and put the login process there, but the #PostConstruct doesn't get called when request.getSession(true) is called.
Thanks!
Jason
I think its not the SessionFixationProtectionStrategy but the ConcurrentSessionControlStrategy.
Set max-sessions="-1" for this code snippet
I did not solve my original question, but I implemented a workaround - expire session in the session expire object instead of attached with #predestroy.
I want to know about setting and un-setting the session in JSF2.0. Although following some blogs and books (Core JavaServer Faces-3rd Edition), i got to know that using annotation #SessionScoped we can set any manage bean to be in session. I have a loginBean which is #ManagedBean and SessionScoped declared. On the top right corner, my web has login button.
When this session is created (i am not setting it manually, that is why i am confused) and when i gets destroyed? It must be destroyed either by time out or by clicking in logout button only.
JSF uses the Servlet API under the covers. A session scoped managed bean is in essence set as an attribute of the HttpSession. It will be created and set whenever the EL expression referencing the managed bean #{sessionBean} is evaluated for the first time. It will be "removed" from the session whenever the session expires (by either a restart of the client or a timeout in the server) or get invalidated. If you let your logout button call ExternalContext#invalidateSession(), then the session will be invalidated.
If you're familiar with the basic Servlet API, you should already understand how this all works. For an in-depth explanation of the Servlet's HttpSession works under JSF's covers, read this answer: How do servlets work? Instantiation, sessions, shared variables and multithreading.
In jsf 2.0 we can set total class ob as session like i mention
Class_name sm;
ExternalContext extContext = FacesContext.getCurrentInstance().getExternalContext(); extContext.getSessionMap().put("Give name for access this property",sm);
Class_name sm = (Class_name) extContext.getSessionMap().get("Give name for access this property");
Background
The application I am working on currently uses Spring + JPA. Everything was working fine before we decided to introduce DWR.
Using DWR I invoke a method on a Service class and it then redirects to the Controller.
try{
return WebContextFactory.get()
.forwardToString("/search.do?searchString=" + searchString);
}catch(...){
}
After this, when the search method is invoked at the DAO, it does not find an pen session.
Session session = (Session) entityManager.getDelegate();
This session here is closed...
I think my changes(of introducing DWR) should not in any way affect the Session creation.
Awaiting inputs.
Shardul.
Issue resolved.
The problem was with the configuration of OpenEntityManagerInViewFilter in the web.xml. It was not intercepting the DWR requests as it was mapped to a
*.do
instead of
/*
Shardul.