views:

397

answers:

8

Hi, I like to know if someone disables the cookies in my browser then cookies dont work for my browser then how can I do sessions in java. I am writing servlets for server side programming. Then how does my sessions work? How does it recognize the user? As JSESSION ID is stored in cookies...

+2  A: 

If cookies are disabled, you can still maintain sessions by sending the value of JSESSIONID as a query parameter, like:

http://www.mywebsite.com/somePage?JSESSIONID=389729387392

Keep in mind that if security is a primary concern then you may not want to use this approach, as it puts the session id right into the url.

danben
+1  A: 

If cookies are disabled, most session providers append a URL parameter called JSESSIONID to maintain session state

Kevin
+8  A: 

See HttpServletResponse encodeURL() and encodeRedirectURL().

These functions will rewrite your URLs appropriately to include the session information if the browser doesn't support cookies. Depending on what Java web framework you're using, these functions may be called automatically (as long as you use the framework's methods for writing URLs).

Note that this may not be desirable in all cases, due to the security and caching implications of making the session ID visible in the links. This page summarizes the issues much better than I can in this short space, and provides a way to disable this feature.

ZoogieZork
+1  A: 

As others have mentioned, you servlet container, e.g. tomcat, automatically resorts to putting the JSESSIONID in the url if the browser doesn't allow cookies. It is configurable in tomcat, as you can see in this answer.

My advice is that you simply try it. Take your web application as it is right now, without changes, and run it in your browser with cookies disabled, and see what happens.

Yoni
The linked answer is wrong. The `cookies="false"` will **permanently disable** the use of cookies to maintain the session and it will **not** automatically rewrite the URL for every request. It will only do so for plain vanilla GET requests (and thus not for POST requests). And still then, you have to change all links in your page to include URL rewriting.
BalusC
A: 

Look at the standard taglibs for JSP-pages, notably the <c:url> tag.

http://onjava.com/pub/a/pub/a/onjava/2002/05/08/jstl.html?page=2

I believe that it also handles the jsession-id attribute if cookies are not available.

Thorbjørn Ravn Andersen
+2  A: 

You need to append the jsessionid to all the URL's involved in your webapplication which are supposed to be invoked by the client. This includes the redirect URL's and the links in the JSP page.

In case of a redirect URL, you need to use HttpServletResponse#encodeRedirectURL() first:

response.sendRedirect(response.encodeRedirectURL("page.jsp"));

In case of links in a JSP page, you basically need to pass those URL's through HttpServletResponse#encodeURL() first. You can do this with help of JSTL's (just drop jstl-1.2.jar in /WEB-INF) <c:url> tag, it will behind the scenes pass the URL through the aforementioned method:

<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
...
    <a href="<c:url value="page1.jsp" />">link1</a>
    <a href="<c:url value="page2.jsp" />">link2</a>
    ...
    <form action="<c:url value="servlet" />" method="post">
        ...
    </form>
BalusC
+1  A: 

For reference, it's good to know that html5 introduces sessionStorage as part of Web Storage. There is a good article on 24ways.org introducing it: Breaking Out The Edges of The Browser.

Support:

  • Latest: Internet Explorer, Firefox, Safari (desktop & mobile/iPhone)
  • Partial: Google Chrome (only supports localStorage)
  • Not supported: Opera (as of 10.10)

HTML5 (including next generation additions still in development)

Gregory Pakosz
people who disable cookies most likely will disable those too.
irreputable
A: 

The other answers are great; I don't need to repeat that. But I do have some additional comments.

Please don't put session data (the entire session) in a cookie, but only a session id, possibly hashed. It's way too easy for people to edit the contents of a cookie. Leave the session data on the server; possibly in a database if you have lots of concurrent users or sessions live very long.

If even the session id itself is very precious you could even put it in a POST parameter, thereby preventing that it occurs in the URL itself.

extraneon