JSESSIONID is a term that you come across frequently while working in the Java web world, but it’s tough to find a good explanation of what it is on internet. I’ll try my best to make it clear.
Let’s lay out some basic vocabulary to make the article easier:
- HTTP: the (main) protocol which runs the internet. When you request a website, typically, it is returned via HTTP.
- Client: an application which requests a resource (e.g. a website) from a server over HTTP. Your web browser is a client, for instance.
- Server: an application which waits for requests from clients and answers them by providing a website.
- Application server: an application on which the server runs. In the Java world, the most frequently used application server is Tomcat, but there are several others like Glassfish, Wildfly, Websphere, etc.
How sessions work
HTTP is stateless. That means that when a client requests a website from a server, each request is independent. This creates a few challenges: for instance, say a server has a private page (only accessible to logged in users) and a page to log users in. Users can log in using the appropriate HTTP request, but how does the next HTTP request, the one that fetches the private page, know that a previous HTTP request authenticated the user, since there is no relationship between both requests that were sent?
To get around this, there are several workarounds. One of them is through cookies. A cookie is a file that contains a long piece of text, that the server sends to the client when the client logs in. After that, the client sends that file to every request to the server; the server checks that the cookie contains text that is knows, and if it does, it knows the user is allowed to access the private page or resource.
It’s important to know this happens almost completely automatically. Developers write clients that run on browsers, and servers that run in application containers; in modern browsers and application containers, the process of cookie sending is automatic and invisible to the developers. All the developer needs to do is configure the security in the server to say “I’d like these pages to be protected with cookies”, and the clients and application servers will do the rest. This makes it easy for developers to secure applications, but difficult for junior developers to understand how it all works – and diagnose when it doesn’t work.
What is a JSESSIONID ?
In the Java world, the JSESSIONID is the name of that cookie that’s sent between an application server and a client. This is not just a convention, it’s always the case: the Java Servlet Specification states that “the name of the session tracking cookie MUST be JSESSIONID” (emphasis mine).
Please note that this is not the way YOU should send the JSESSIONID to your application. The URL rewriting process happens under the hood between the client and the server, and must not be used as a workaround in case you don’t understand how the two are communicating. Security is an extremely sensitive concern in the design and development of an application. The best thing you can do is use your tools, languages and frameworks as they were meant to.
Diagnosing JSESSIONID issues
I’m getting 401 not authenticated responses from my server even though I logged in. How can I ensure that the JSESSIONID is being transfered ?
If your client is a browser, right-click the web page and click “Inspect”, then select the “Storage” tab in your developer tools. Under “Cookies”, if your browser received the JSESSIONID, then it should appear here.
You can also ensure it is being sent with your request. Click “Network” tab, then click on the request that is being returned a 401. Under “Request headers”, you should find a header with name “Cookie” and value starting with “JSESSIONID=”.
Sources and further reading
Java Servlet Specification 2.4, section SRV.7.1.1