Develop Reference

Same JSESSIONID but different Session Object

I have an Java Http Servlet and trying to store things into the session. I have checked the request header and the same JSESSIONID is being sent each request.
However, every time, the session object (id) is different AND it contains none of the properties that we set in the last request.
More details: This works fine with just Tomcat7, but when I try to use nginx as a frontloader, the cookie is still sent, but the session object is still different.
Looks like the request URL is a fully-qualified domain.
Any ideas on what would be causing this or how to debug?
Thanks!

Servlet session without cookies + ajax requests that only return JSON

Here's my situation, I have a web site that I just load using Apache HTTPD that then makes Ajax POST requests to a servlet which returns only JSON data. That JSON data is then used to update tables, etc..
Now I want to add user logic to my site, and also maintain servlet sessions for requests made by individual users.
I understand that the servlet needs to return the session id generated by the first call to request.getSession(), so that the client can add this sessionid to future Ajax requests in order for the servlet to know which session in memory to use.
I also understand that the two ways that this session id can be returned to the client is either using cookies (JESSIONID) or URL Rewriting.
If I can't use URL Rewriting, because I'm just returning JSON data, are cookies the only way I have left to send back the session id to the client?
Also, as a side question, currently I noticed that there is no JSESSIONID cookie in any of my HTTP responses from the servlet. Someone suggested to me that this was something new in Tomcat7 and that I had to activate them in the global context.xml. Does this mean that by default there is no session handling even if you make calls to request.getSession() ?

You have correctly identified two of the three ways of handling session IDs supported by Tomcat. There is a third way to track sessions but only if the application runs over SSL. In that case you can configure Tomcat to use the SSL session ID.
If the Servlet calls request.getSession() then Tomcat always includes a session ID in the response. However, those cookies are marked as httpOnly by default in Tomcat 7 onwards which means they are not visible to javascript (to protect against XSS attacks that try to steal the cookie). If the session cookies need to be visible to script then you need to set useHttpOnly="false" in either the web application's context.xml (to change the default for just that file) or in $CATALINA_BASE/conf/context.xml to change the default setting for every web application.

How do I keep Struts2 from appending jsessionid to the URL (on redirects)?

I want to keep the jsessionid parameter out of the URLs generated by Struts, but can't seem to find a configuration parameter or similar. To be honest, I don't even know exactly at which level this is handled.
Specifically, Struts (or the servlet engine) puts a sessionid in the URL when it's redirecting with a 302 and the session has not been established before (i. e. the redirect is in response to a request that sent no Cookie header). The response also contains a Set-Cookie header.
Generally, I just don't want the session id in the URL, ever. No cookies, no session.

You can try to check what's your servlet container offers to solve this problem. Alternatively you can write a filter to get rid of jsessionid. Hae a look here for details: http://seamframework.org/Documentation/RemovingJSESSIONIDFromYourURLsAndFixingScache

Java Servlet/JSP Cookie Disconnect

I'm having a strange issue with cookie visibility between an authentication servlet and our actual jsp. We're using a servlet to authenticate that the user is a valid user, and if they are, we go ahead and add a cookie to the HttpServletResponse with their referer url (this is so that integrations can be redirected to their own login page on logout). Logout operations go through the same servlet, and the cookie is retrieved, and the user directed back to the stored cookie url. This all works.
However, within my site, if I print out the cookies pulled through the pageContext.getRequest().getCookies() [Or through firebug's console] I do not find the cookie I stored at all. There's literally no trace of it. Yet, when you click the logout link, and are directed back to the authentication servlet, the cookie is found, and the redirect followed accordingly.
The thing is, I need to handle timeout operations in the same ways as logouts, but the timeout check is external to the servlet, in a jsp tag. Since the timeout can't find the cookie, it's just using the standard timout page, which the integrating customer wouldn't want to see.
Any ideas what's going on here?
[ANSWER]
It turned out to be a path issue. I know I didn't paste any code, but I was creating the cookie without setting a path, so the cookie was only visible within the servlet directory. Once I set a path of "/" the cookie was visible throughout the site.

When you say "within my site", does that mean that your site is deployed on a different (sub) domain? Cookies by default are only visible to host they were set from, meaning cookie that was set from "www.example.com" will not be visible to "other.example.com". You can get around that by explicitly specifying cookie domain to be common for both (e.g. "example.com").

How are you doing this redirect?
RequestDispatcher's forward method takes request and response objects, presumably the ones you were already working with. This means that the request object is the same HttpServletRequest object that you were dealing with in the Servlet.

Actually, it turned out to be a path issue. I know I didn't paste any code, but I was creating the cookie without setting a path, so the cookie was only visible within the servlet directory. Once I set a path of "/" the cookie was visible throughout the site.

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.