I have two webapps loaded from one embedded jetty server. Both apps are using Spring MVC.
Sessions are managed by manipulating HttpSession objects in the controller methods.
(request.getSession() and session.invalidate(), etc)
But suppose a user signs in on web app A, and session is created on web app A. When the same user hits web app B, can the app read and recognize the same session that's being used in A? Or do two web apps have completely separate session managements? I see the browser stores a JSESSION cookie, so I wonder if two apps would use the same JSESSION cookies?
I did search around and had no luck, probably related to embedded jetty having mutliple apps is a bit uncommon.
Thank you so much!
There is answer in scope of tomcat, but looks like the same is possible for jetty
Related
We use Apache Shiro to provide security for 4 applications running within one Tomcat instance. They are deployed as 4 WARs, with all the Shiro config and security in a 5th WAR.
In order to provide SSO across these applications, we've configured ehCache to share sessions between all 5 web apps (the original intention was to use multiple containers, but this never happened).
The problem we are facing is that in sharing the sessions across the apps, we are also sharing all object data placed into the session. This is a problem because the apps have different dependencies and hence different classpaths, leading to ClassNotFoundExceptions. I think I'm right in saying that by default in a Tomcat container each WAR would have a separate session and so this would not be problem, but then we would not be able to share the Shiro user data!
So my question is this: Is it possible to have separate Shiro and Container sessions? This would allow the desired outcome i.e. any login data that Shiro uses would be placed into the 'Shiro' session and shared across the multiple apps, while the Container sessions would be separate for each app and therefore no data would be shared between them.
Shiro needs to run in each container. Then those containers need to share the Shiro session. https://shiro.apache.org/session-management.html#session-storage
You could do this using the container's session sharing capabilities or with Shiro's.
I have multiple wars deployed in the same Jboss instance.
One of the wars will be hosting a Login page that will let the user sign in.
on sign in, the system creates a User Session. Now, the user tries to navigate another module 'http://site/notsigninmodule' the user session should be still available to the 'notsigninmodule' app.
Does anyone know how to achieve this? An example would be most useful
After days of research, this is what i came up with
Sharing sessions between web applications would violate the JavaEE Servlet specification,apparently.
"Session information is scoped only to the current web application (ServletContext), so information stored in one context will not be directly visible in another"
In 2013/2014 The following feature request JIRAs were opened for community versions.
https://issues.jboss.org/browse/JBAS-9545
https://issues.jboss.org/browse/WFLY-1891
Now, in the community version wildfly 9 This feature is available: https://docs.jboss.org/author/display/WFLY9/Web+(Undertow)+Reference+Guide
So my conclusion is that in jboss 5.1, i cannot achieve my rqm.
I opted to bringing in the jsp pages into the web app that creates the session.
I have two web application running on same server.
I want to send objects from one servlet in Application1 to another servlet in Application2. How can i do that?
Will the session object be same for both the app if running on same
server?
How can i share the session object across the applications?
What if both web applications are on different server?
Please provide link of any good article which address the above issue since i am unable to find one.
I am not an experienced web developer but lately I have been involved in the development of some web applications (Java Servlets + JavaScript + HTML5). With experience in standalone projects this question makes sense to me but I understand it can be absurd for an expert web developer:
I would like to develop some common applications and integrate them into bigger projects.
For example, I would like to develop an users manager web app which could be used by different products. So I could encapsulate it into a WAR file and include it in a project or another.
As it is explained here, I understand a WAR package is not a JAR containing libs but a package to deploy a complete application.
My goal is to reuse the same code without having to include all "UsersManager" files one by one into App1 and App2 packages. Currently, I think the best solution is to publish "UsersManager" and call it from App1 or App2. Nevertheless, if "UsersManager" and "App1", for example, are published at different contexts they don't share session variables. If "UsersManager" includes a Login service and it creates some session data these session variables should be accesible from "App1".
What should I try?
Make a redirect call from App1/App2 to UsersManager?
Forget about sharing sessions?
What is the right solution to this kind of problems?
Since Geronimo will use a Cookie to store the client session anyway (at least with my configuration),
all the web applications will require the client to accept Cookies.
On the other hand, at my company we have already a centralized session manager. I will use an additional cookie to store the session id provided by that system so that I have already a simple SSO mechanism.
let say in tomcat application server we deployed 2 web applications , web application A, web application B. How to pro-grammatically sync session from web application A to web application B . In other words, as long as user login to web application A, he is already login to web application B. As well when he log out.
You may check Sharing session data between contexts HOW-TO to see if it solves your problem.
Is this about authenticating user only once with same username and password for multiple sites?
If so google Single Sign On. There are a number of frameworks out there for doing just that.
Use the single sign on valve.