Develop Reference

Sharing session data between two war files

I have two war files such as war1 and war2
If am login the application, the session will be created in war1 and from that if am navigate to war2, there i need the same session data.
I tried crossContext=true in context.xml of server from that i can access the data by storing it in servletContext.
But the issue is once i logined the screen in chrome the session data will be stored in servletContext and the data will maintain till the application is running.
If am giving the same URL in another browser like IE here also, i can get the servletContext data so instead of navigate to login page the corresponding screen will be opened
Kindly suggest me how can i overcome this issue in java?
Is there any way to findout browser switching or incognito window mode of the browser in java?
Note: am using tomcat server

I have never dealt with your exact configuration problem, but even if you can make this work on a single Tomcat instance, you might have problems should your two web applications ever be distributed across multiple Tomcat instances.
So, I am going to suggest that you actually use a database to store state which needs to be passed between the two applications in a safe and reliable way. Note that the database approach also scales nicely in a distributed environment, so long as you have a single logical database.

While session replication indeed can be done in Tomcat (see here) I really suggest you to avoid this type of issues by eliminating the session altogether.
This session replication is an approach that was somewhat common before ~15-10 years, but nowadays when we have a lot of servers running in parallel to serve user requests and have elastic clusters, this approach is not good enough because basically it doesn't scale well.
There are many ways to achieve what you want, though:
Use a shared database to store the session information. Add some session Id to the response and require the client to pass this id back into all subsequent request along the session. Then execute a query to the Database by this Id and retrieve all the session information.
This solution also doesnt really scale well, but then you can shard the session information if the db permits to do so...
Use Redis/Aerospike to save the session information of the currently connected user. somewhat like DB approach, but since redis run in-memory it will be much faster. In general, this approach can be used in conjunction with 1 where redis is an in-memory cache.
Encrypt the session information or even just sign cryptographically and send back to client. Client will have to supply this information along with the request without knowing which server will actually serve this request.
Without delving into cryptography I'll just state that encryption can be done if you don't want client to see the session information (despite the fact that this is the user whose information is supplied) and signature is used to prevent tempering the data (while sending it back to server).
The data can be supplied to server from client via Header or cookie for instance.

Explicitly set JSESSIONID

So, I'm in the middle of building an application where I want the user to be able to send a link to another user and work on the same data. There is little need to persist the data for more than 15 minutes and I want the application to not have to rely on a database.
I have a few variables which I am currently storing in a HttpSession.
Ideally I'd like to be able to set a parameter "sid" in the URL, and use that to set the session ID on the second client's browser - the one that's received a link with the SID.
Unfortunately, there seems to be no way to change the SID of a current session once it's been set up.
The only solution I've come up with so far is referring to the doGet() with a HttpPost.setHeader("Cookie", "JSESSIONID="+ getSessionId()) method, and getting the data with a specific session that way, but this seems pretty clunky.
Any suggestions?
EDIT
This has seemingly turned into a discussion about the wisdom of setting two users up to have the same session so session vars may be kept the same. Note that a non-db, ie light weight solution was what I was looking for. PHP allows you to arbitrarily set a session ID to do this, but I'm deploying to Tomcat in this instance. Something which allows lightweight sharing of a few parameters, that's it...
What I've done, then, is to set context vars using context.setAttribute(). Ugly as sin, but all I can come up with, unless anyone has any better ideas.

This approach has some security issues because you are simulating [session hijacking] with it 1:
In computer science, session hijacking, sometimes also known as cookie
hijacking is the exploitation of a valid computer session—sometimes
also called a session key—to gain unauthorized access to information
or services in a computer system. In particular, it is used to refer
to the theft of a magic cookie used to authenticate a user to a remote
server. It has particular relevance to web developers, as the HTTP
cookies used to maintain a session on many web sites can be easily
stolen by an attacker using an intermediary computer or with access to
the saved cookies on the victim's computer (see HTTP cookie theft).
Better approach is to set your data in a way that both users can approach it from their sessions. If you are using single server you can do that with some global data within a server. In clustered or cloud environments you'll need some common storage for that (ie. database, global cache, etc.)
EDIT
You are on a right track to share data among two users with different sessions.
There is one context per "web application" per Java Virtual Machine
where an attribute allows a servlet container to give the servlet
additional information.
Attributes are meant to be used to share data inside container among servlets of the same web application.
For clusters:
In the case of a web application marked "distributed" in its
deployment descriptor, there will be one context instance for each
virtual machine. In this situation, the context cannot be used as a
location to share global information (because the information won't be
truly global). Use an external resource like a database instead.

Does the Play! framework have any built in mechanism to prevent session hijacking?

I've read that the play framework solves the session fixation issue by hashing the session id with the application key, but does it provide any mechanism to prevent session hijacking, or is this left up to the implementor?

The play documentation has a good section on security, so rather than duplicate, here is a link - http://www.playframework.org/documentation/1.2.4/security.
It covers
XSS
SQL Injection
Session security
Cross site request forgery
Some you have to implement yourself, others you don't.
Your specific question about session hijacking is automatic.
The session is a hash of key/values, signed but not encrypted. That
means that as long as your secret is safe, it is not possible for a
third-party to forge sessions.

No, there is no built in way to prevent the hijacking of a session as soon as one is able to capture the session cookie (through sniffing/man in the middle).
There are some ways to make it harder, e.g.:
using only https
setting application.session.httpOnly in application.conf
One approache to make it harder is:
- store the ip/user-agent/resolution/other stuff or a hash of that also in the session.. in your controller you then check if the user that accesses your site still recreates the same hash... the only real problem is with people that are using a proxy that e.g. changes the ip on the fly because of clustering.
A little trick you could try to use: (works only in recent browsers)
When a user logs in, store some stuff in a HTML5 local storage. Modify your Ajax calls to supply this information from the local storage. If the information is missing/invalid, you can invalidate the whole session. But you'll have to make sure, that the checks only get applied against requests from HTML5 browsers.
hope this helps a bit.

What is session management in Java?

I have faced this question in my Interview as well. I do have many confusion with Session Scope & it management in java.
In web.xml we do have the entry :
<session-config>
<session-timeout>
30
</session-timeout>
</session-config>
What does it indicate actually ? Is it scope of whole project ?
Another point confusing me is how can we separate the session scope of multiple request in the same project? Means if I am logging in from a PC & at the same time I am logging in from another PC, does it differentiate it ?
Also, another confusing thing is the browser difference. Why does the different Gmails possible to open in different browsers ? And Gmail can prevent a session from Login to Logout. How is it maintained with our personal web ?

Session management is not something limited to Java and servlets. Here's roughly how it happens:
The HTTP protocol is stateless, so the server and the browser should have a way of storing the identity of the user through multiple requests
The browsers sends the first request to the server
The server checks whether the browser has identified with the session cookie (see below)
3.1. if the server doesn't 'know' the client:
the server creates a new unique identifier, and puts it in a Map (roughly), as a key, whose value is the newly created Session. It also sends a cookie response containing the unique identifier.
the browser stores the session cookie (with lifetime = the lifetime of the browser instance), containing the unique identifier, and uses it for each subsequent request to identify itself uniquely.
3.2. if the server already knows the client - the server obtains the Session corresponding to the passed unique identifier found in the session cookie
Now onto some the questions you have:
the session timeout is the time to live for each session map entry without being accessed. In other words, if a client does not send a request for 30 minutes (from your example), the session map will drop this entry, and even if the client identifies itself with the unique key in the session cookie, no data will be present on the server.
different gmails (and whatever site) can be opened in different browsers because the session cookie is per-browser. I.e. each browser identifies itself uniquely by either not sending the unique session id, or by sending one the server has generated for it.
logging from different PCs is the same actually - you don't share a session id
logging-out is actually removing the entry for the session id on the server.
Note: the unique session id can alternatively be stored:
in a cookie
in the URL (http://example.com/page;JSESSIONID=435342342)
2 or 3 other ways that I don't recall and aren't of interest

What does it indicate actually ?
The lifetime of a session. The session expires if there is no transaction between the client and the server for 30 minutes (per the code segment)
Is is scope of whole project ?
It has application scope. Defined for each web application
Another point confusing me is how can
we separate the session scope of
multiple request in the same project?
Means if I am logging in from a PC &
at the same time I am logging in from
another PC, does it differentiate it ?
Yes. The session ids (JSESSIONID for Apache Tomcat) will be different.
Also, another confusing thing is the
browser difference. Why does the
different Gmails possible to open in
different browsers ?
Each login by the same user from a different browser is a different session altogether. And the cookies set in one browser will not affect in another. So different Gmail instances are possible in different browsers.
And Gmail can prevent a session from
Login to Logout. How is it maintained
with our personal web ?
Persistent cookies

Servlets in Java have an HttpSession object which you can use to store state information for a user. The session is managed on the client by a cookie (JSESSIONID) or can be done using URL rewrites. The session timeout describes how long the server will wait after the last request before deleting the state information stored in a HttpSession.
The scope is per browser instance, so in the example you give logging in from two different pcs will result in two session objects.

if you open the same application in different window i mean multiple instance of a browser it will create different session for every instance.

I recommand Apache Shiro for session management,Authentication and authorization.
I take it back.
As #BalusC commeneted below, only servlet container is in charge of managing the http session. Shiro is just using that. It will hook to HttpSession via a filter you explicitly define.

we have 4 ways to manage a session.
1.Cookies
2.URL rewriting
3.Hidden form fields
4.HTTP session
the fourth one is powerful and mostly used now-a-days.

Best option for Session management in Java

Best way managing session in Java. I heard that cookies are not reliable option for this as they gets stored into browser and can be accessed later on? Is this correct? If possible please come up with the answers with the coding example.
Which is the best among:
URL Rewriting: Server will add an additional parameter at the end of URL link
Hidden parameter in Form: server will add an additional parameter at every form in HTML
cookie: Server will ask browser to maintain a cookie.

The session management (client identification, cookie handling, saving session scoped data and so on) is basically already done by the appserver itself. You don't need to worry about it at all. You can just set/get Java objects in the session by HttpSession#setAttribute() and #getAttribute(). Only thing what you really need to take care of is the URL rewriting for the case that the client doesn't support cookies. It will then append a jsessionid identifier to the URL. In the JSP you can use the JSTL's c:url for this. In the Servlet you can use HttpServletResponse#encodeURL() for this. This way the server can identify the client by reading the new request URL.
Your new question shall probably be "But how are cookies related to this? How does the server do it all?". Well, the answer is this: if the server receives a request from a client and the server side code (your code) is trying to get the HttpSession by HttpServletRequest#getSession() while there's no one created yet (first request in a fresh session), the server will create a new one itself. The server will generate a long, unique and hard-to-guess ID (the one which you can get by HttpSession#getId()) and set this ID as a value of the cookie with the name jsessionid. Under the hood the server uses HttpServletResponse#addCookie() for this. Finally the server will store all sessions in some kind of Map with the session ID as key and the HttpSession as value.
According to the HTTP cookie spec the client is required to send the same cookies back in the headers of the subsequent request. Under the hood the server will search for the jsessionid cookie by HttpServletRequest#getCookies() and determine its value. This way the server is able to obtain the associated HttpSession and give it back by every call on HttpServletRequest#getSession().
To the point: the only thing which is stored in the client side is the session ID (in flavor of a cookie) and the HttpSession object (including all of its attributes) is stored in the server side (in Java's memory). You don't need to worry about session management youself and you also don't need to worry about the security.
See also:
Authenticating the username, password by using filters in Java (contacting with database)
How to redirect to Login page when Session is expired in Java web application?
How to implement "Stay Logged In" when user login in to the web application

All Java web frameworks support cookies or URL-encoded session IDs. They will chose the correct approach automatically, so there is nothing you need to do. Just request the session object from your container and it will handle the details.
[EDIT] There are two options: Cookies and a special URL. There are problems with both approaches. For example, if you encode the session in an URL, people can try to pass the session on (by putting the URL into a mail, for example). If you want to understand this, read a couple of articles about security and build app servers. Otherwise: Your Java app server will do the right thing for you. Don't think about it.

The cookie just stores the session ID, this ID is useless once the session has expired.

Servlet specification defines the API for accessing/setting session data in standard J2EE application. Also it defines that session data is stored on the server-side and nothing is transferred to the client except the session identifier. There are 2 mechanisms how session id is transferred:
1) request URL e.g. jessionid=....
2) cookie
Mechanism is determined automatically based on client capabilities.
EDIT. There is no best option, there is servlet specification that defines the way.

Http is a stateless, client-side pull only protocol.
To implement a stateful conversation over it, Java EE Web Server need to hide some information (which is sessionid) in client-side and the mechanism it can use should follow HTTP and HTML spec.
There are three ways to accomplish this goal:
URL Rewriting: Server will add an additional parameter at the end of URL link.
Hidden parameter in Form: server will add an additional parameter at every form in HTML.
cookie: Server will ask browser to maintain a cookie.
Basically, modern web server will have a "filter" to choose which way to use automatically.
So if Server detected that browser already turn off cookie support, it will switch to other ways.

2 important questions:
Which web technology are you using? JSF, Struts, SpringMVC or just plain servlets/JSPs.
Servlets/JSPs already give you the session support you need. JSP Example: Hello, <%= session.getAttribute( "theName" ) %>
I really don't think you have something to worry about cookies, since the data is stored safely in the server and handeling the cookie is done automaticlly.
Is your application installed on a single server?
If YES than you have no problem, use the servlet session option.
if NO than you gotta find another way to do this. Like using a sticky session, or maybe parse the entire session object in the requests/responses as a field. This option indeed requires you to take security measures.