In my application I want to update the jsessionid value from sessionid to quit or null. I'm performing following actions to do this thing but it is not working fine.
Cookie cookie = new Cookie("JSESSIONID","quit");
cookie.setDomain(domain);
cookie.setPath("/"+path);
cookie.setMaxAge(0);
reponse.addCookie(cookie);
and tried with set-cookie in headers also. I'm not able to change the cookie value. Temporarily, I am overriding with javascript, but it won't work if we enable cookie as httpOnly; and one question am I able to change the value of jsessionid if it is marked as secure.
I have multiple applications so multiple jsessionids are creating I tried to set/update those values by adding above code in response to update.
When I observed in Firefox the jsessionid is still there and continuing for next request cycle also. How can I change the jsessionid value through java. I can update with javascript but the cookies are enabled with HttpOnly flag to true.
Related
I have a small confusion about Cookies, whenever the user is logging in we create cookies and adding to the response header.
Cookie cookie = new Cookie("sessionId", "232hghjghghgh"); // http cookie.
cookie.setVersion(1);
cookie.setPath("/");
cookie.setMaxAge(1000);
response.addCookie(cookie);
I think the above will be setting into the browser cache and we can get it from the browser cookies.
In our GWT module we already have an existing implementation like
Cookies.getCookie("sessionId"); // Cookies are from GWT
We are able to get the cookie using above line without using anywhere Cookies.setCookie() method.
Is that because of above line response.addCookie(cookie).
Could any body tell me, is my assumption correct?
Yes. Your first example is using a javax.servlet.http.Cookie, and this happens on the server side. The latter is purely GWT (i.e. client side) and returns java.lang.String (i.e. the String value of the cookie). But of course both are conceptually the same and setting one on the server will make the other show up on the client.
I have my GWT code in an index.jsp page, and when I view the page info (security/cookies), I see the JSESSIONID cookie assigned to 'subdomain.mysite.com'.
When in my client-side code, I do this:
Window.alert("cookies=" + Cookies.getCookieNames().toString);
I see two cookies that are assigned to 'mysite.com', but I do not see the JSESSIONID. The current url for the page is 'subdomain.mysite.com' - shouldn't it be giving me the cookie?
When I refresh, or display the cookies on a click event, I still do not see the JSESSIONID cookie.
Why can't I get it on the client side?
Is your application server configured to set the HTTPOnly flag on the JSESSIONID cookie? If so, client side code will not be able to see it
See https://www.owasp.org/index.php/HttpOnly
It is generally good security practice to set the HTTPOnly flag - can you clarify why you want access to the JSESSIONID cookie in your client side code?
That will indeed happen if the HTTPOnly flag is set on the cookie, as explained by Chi. If your sole purpose is to get the current session ID in JavaScript context, then you could just let JSP/EL print it as if it's a JS variable:
<script>var jsessionid = '${pageContext.session.id}';</script>
I'm posting some strings in my Session with the call
request.getSession().setAttribute(key, value);
And making the redirect with
response.sendRedirect(urlRedirect);
In almost all cases the values is there after the redirect.
But sometimes I can only read this value in the next page view, not in the redirect. There is no common behavior.
Someone has faced the same problem?
Sessions are backed by a HTTP cookie. On first-time session creation, a cookie will be set in the response header. By default, cookies are bound to a specific context only.
So, if you redirect while the cookie hasn't been set yet, the session will get lost. To go around this, you need to encode the redirect URL.
response.sendRedirect(response.encodeRedirectURL(url));
This appends the jsessionid identifier to the URL which allows the servletcontainer to locate the right session without help of a cookie.
If you don't like the jsessionid thing, then consider implementing a filter like this which ensures that the client is aware of the session cookie before the request enters your controller wherein you fire the redirect.
Also, if you redirect to a different context, it won't be able to access the same session. To go around this, you need to configure the servletcontainer to share the session among the contexts. In for example Tomcat, check the emptySessionPath attribute of the <Connector> element in /conf/server.xml.
Such a behaviour can be caused by caching.
If the page you are redirecting to is retrieved from the browser cache, you obviously can't see the result of setAttribute() on it. So make sure it's actually requested by the browser.
Are you sure you need to do redirect through browser (response.sendRedirect()) and not on the server side (RequestDispatcher.forward())? Latter is faster as there are no network round trip.
The problem was solve by changing the way of submit.
The page was submitting the data only changing the value of location.href to the Servlet Action.
We only call the submit function from the page form, and the session attributes works fine!
I'm trying to set the httponly flag on the JSESSIONID cookie. I'm working in Java EE 5, however, and can't use setHttpOnly(). First I tried to create my own JSESSIONID cookie from within the servlet's doPost() by using response.setHeader().
When that didn't work, I tried response.addHeader(). That didn't work either. Then, I learned that the servlet handled converting the session into a JSESSIONID cookie and inserting it into the http header so if I want to play with that cookie, I'll have to write a filter. I wrote a filter and played with setHeader()/addHeader() there, again to no avail.
Then, I learned that there's some flush/close action going on in the response object before it gets to the filter so if I want to manipulate the data, I need to extend HttpServletResponseWrapper and pass that to filterChain.doFilter(). This is done but I'm still not getting results. Clearly I'm doing something wrong but I don't know what.
I'm not sure if this is at all relevant to the question at hand but no html document is being returned by the servlet to the browser. All that's really happening is that some objects are being populated and returned to a JSP document. I've sort of assumed that The Session object is turned into a JSESSIONID cookie and wrapped -- along with the objects added to the request -- in an http header before being sent to the browser.
I'd be happy to post some code but I want to rule out the possibility that my difficulties stem from a misunderstanding of the theory first.
Since the JSESSIONID cookie is managed by the servletcontainer, this setting is servletcontainer specific. It's unclear which one you're using, so here's an Apache Tomcat 6.0 targeted answer so that you know in which direction you'll have to look for your servletcontainer: you need to set the useHttpOnly attribute of the webapplication's <Context> element to true.
<Context useHttpOnly="true">
...
</Context>
Also see this Tomcat documentation about the <Context> element.
You can use this with Java EE 5:
For Java Enterprise Edition versions prior to Java EE 6 a common workaround is to overwrite the SET-COOKIE http response header with a session cookie value that explicitly appends the HttpOnly flag:
String sessionid = request.getSession().getId();
// be careful overwriting: JSESSIONID may have been set with other flags
response.setHeader("SET-COOKIE", "JSESSIONID=" + sessionid + "; HttpOnly");
Source : https://www.owasp.org/index.php/HttpOnly
I test it into a filter
I have found a strange behaviour (strange for me, a novice :D) in my project.
Basicly after an action I create or update a cookie (if it exists or not) and send it to the client. The strange thing is that in the jsp I can read the cookie ONLY when I update its value (and I get the updated value, not the old one) but not the first time, when I create it (I can see the cookie using a browser tool but seems that the jsp can't read it).
Is this a normal behaviour? If yes, what do you suggest to do in order to have the cookie information available also at the first time?
Thanks very much!
Roberto
If you create or update a cookie, it will be stored in the response header. If you request a cookie, it will be requested from the request header.
I think your problem is that you're forwarding the same request from servlet to JSP and that you expect that the new cookie is already available in the request header. This is not true. The new cookie is only available in the subsequent requests.
You have 2 options:
Redirect to JSP. A redirect will create a new request.
Store the data of interest as request attribute and let EL in JSP access it.
By the way, I saw in one of your comments that you're using plain Java code to read cookies in a JSP. I would only say that using scriptlets in JSP is a bad practice. You can access cookie values easily in EL as follows:
${cookie.cookiename.value}
[Edit] oh my, now I see that this is an old topic. Hopefully my effors weren't all for nothing :/
Cookies are stored on client, and so if the response doesn't gets to the client yet, its value is not updated, but it should be available on the next requests.
cookies are used to identify clients when they send you any requests. here's what you are doing when you set the cookie up. you are sending the cookie to the client along with response. And when that client send his next request the cookie that you set comes along with it. so, in the jsp page where you are setting up the cookie, you don't have a request from the client with cookie! so you can't read it. but what you can do like what jerjer has said above. (i.e use a temp and store cookie's value in it and don't try to retrieve cookie. just read the temp value). And i see you say you can read the cookie only when you update. You will be able to read cookie's value from future reqests after cookie is set even if you don't update it. Hope this helps.