I'm developing an environment with 2 webapps deployed in Tomcat 7. One authenticate users using form, openid, remember me cookie or x509 cert. This one works as expected and use the Remember me cookie to authenticate properly when generated.
The problem resides in the second one (the client):
When the login request comes back to the client from the first one, I don't see any cookie. I'm pretty sure they are in the same domain (localhost) and the cookie path is "/" but the browser (firefox) is not sending the cookie to the client.
If I want to use the generated remember me cookie to authenticate in the client, do I need to include all remember me cookie stuff from Spring's security?
Is the remember me cookie a good approach? Do I need something like siteminder or other better approaches?
Thanks in advance. Answers will be voted
Check the cookie information when it is sent back from the server (use Firebug to monitor the network traffic if you're using Firefox).
Check the domain and path, and also whether the cookie is flagged as secure. If the remember-me cookie is issued over a secure connection it will be marked as secure and the browser won't send it over HTTP.
If this is the case, you have to explicitly override it (though you're better to use HTTPS throughout). There's a use-secure-cookie attribute in the remember-me namespace element which you can set.
My application is using websphere 6.1.
And there is no configuration done for setting the cookies secured.
But when I test my application's cookies using mozilla firefox addon : firbug, I can see that few of the cookies are secure and few of them are not.
So I want to know what parameters decides that a cookie should be secure or not.
Sorry for not sharing code / cookie information due to some security constraints.
I am stuck with a jsession id problem. I am using Tomcat 7, Spring framework 3.1.1, security with Spring Security.
Our application has a login page with an url like : defaultSubdomain.theSite.com/login.html. Some of our users have their own subdomains, so their login page url are : subdomainForUser.theSite.com/login.html.
The problem is, if one of them use the default login url :
he will be log in, an HttpSession will be created on the server and a JSESSIONID cookie will be created on defaultSubdomain.theSite.com on client, then
our server makes the browser redirect to the welcome page of user's subdomain and makes the browser recreate the JSESSIONID cookie with javascript.
In a filter:
//if client is on the wrong subdomain
HttpServletResponse.sendRedirect(url);
return;
But after that, client still needs to log in again. Is there any way to achieve what I try to do (with a coding approach and not configuring tomcat)?
I made some research and we could use
<Context sessionCookieDomain=".theSite.com" sessionCookiePath="/">
but it implies having one configuration for dev, one for test and one for prod which is not acceptable.
Thanks!
What are the reason that Glassfish resorts to URL rewriting when I am using the latest Chrome browser and logging in to the application without having turned off cookies? Anything I have forgotten to configure or what? It happens randomly.
The JSESSIONID is the value that determines the current HTTP session for the user. It is typically stored in a browser cookie (named JSESSIONID) to connect requests with the appropriate session object on the server.
The reason why the JSESSIONID is not present in the original request is probably because the server has not had the opportunity to send it back to the browser. Any links on a page (using c:url, for example) without a current JSESSIONID cookie will be generated using URL rewriting (the URL will contain the jsessionid). On subsequnt requests, after the JSESSIONID has been stored as a browser cookie, the URL rewrite does not happen.
If the user's browser does not support cookies (or the use of cookies has been turned off) the URL rewriting will allow the user to keep connecting to the same session by the jsessionid added to each URL.
However, if you want to turn off the URL rewriting, you can do this by setting the enableURLRewriting property to false, in the glassfish-web.xml file
<property name="enableURLRewriting" value="false"/>
You may also have luck removing the URL rewrite by ensuring that the appropriate cookie exists and redirecting to a more appropriate URL.
I have this big issue. My current session is gone every time I made a new request to Server.
I have checked in a lot of places. I can't find what's the problem. I also have included
session-config in web.xml both in tomcat and application. I also enabled to accept cookies to my browsers. Tested in every browser. It's not working.
I am just developing a simple java ee applcation using JSP/Servlet. I am facing the problem only after I have deployed to tomcat in server machine.
One possible cause for this is having a "naked" host name (i.e. one without a domain part). That's fairly common if you're working in an Intranet.
The problem is that almost all browsers cookies will not accept cookies for hostnames without a domain name. That's done in order to prevent evilsite.com from setting a Cookie for com (which would be bad, as it would be the ultimate tracking cookie).
So if you access your applicaton via http://examplehost/ it won't accept any cookie, while for http://examplehost.localdomain/ it will accept (and return) the cookie just fine.
The nasty thing about that is that the server can't distinguish between "the browser got the cookie and ignored it" and "the browser never got the cookie". So each single access will look like a completely new sesson to the server.
After years, I never posted the answer back here. At that time I was busy and forgot about this question. But, today I am looking for a solution in Stackoverflow as usual and saw this notification mentioning I am getting points from this Question. Seems like other developers are facing the same issue. So, I tried to recall how I solved the issue. And yes, I solved by manually put back the session id to track/maintain the session id.
Please see the code that I manually put back jsessionid inside the servlet.
HttpSession session = request.getSession();
if (request.getParameter("JSESSIONID") != null) {
Cookie userCookie = new Cookie("JSESSIONID", request.getParameter("JSESSIONID"));
response.addCookie(userCookie);
} else {
String sessionId = session.getId();
Cookie userCookie = new Cookie("JSESSIONID", sessionId);
response.addCookie(userCookie);
}
First check if the webapp's context.xml does not have cookies="false" configured.
Further it's good to know that cookies are domain, port and contextpath dependent. If the links in the page points to a different domain, port and/or contextpath as opposed to the current request URL (the one you see in the browser's address bar), then the cookie won't be passed through which will cause that the session cannot be identified anymore and thus you will get a new one from the servletcontainer.
If that is not the cause, then check if you aren't doing a redirect on every request using HttpServletResponse.sendRedirect() for some reason. If you do this already on the very first request, then the cookie will get lost. You'll need to replace
response.sendRedirect(url);
by
response.sendRedirect(response.encodeRedirectURL(url));
In Your properties
server.session.cookie.http-only=true
server.session.cookie.secure=true
Remove these settings, it will retain your session id cookie, which is being reset with every request.
I experienced a stale https session cookie (my ad-hoc term) problem, due to a secure flag.
I had this problem when switching between http and https. The cookie stored by https session was never overwritten by http session. It remained in FireFox memory for eternity. It was visible in FireFox Tools / Options / Privacy / Delete single cookies where in Send for field it was Only for secure connections. Clearing this single cookie or all cookies is a workaround.
I was debugging the problem with wget, and I noticed such a header:
Set-Cookie: JSESSIONID=547ddffae0e5c0e2d1d3ef21906f; Path=/myapp; Secure; HttpOnly
The word secure appears only in https connections and creates this stale cookie. It's a SecureFlag (see OWASP). There are ways to disable this flag on server side, which seems like a permanent solution, but maybe not safe.
Or is it a browser bug, that the cookie is not overwritten?
Try adding the Live Http Headers plugin to firefox, and make sure the session cookie is indeed being passed to the browser from the server, and make sure the browser is sending it back again on the next request.
Please verify if the session is not being invalidated in your code someplace. Look for code similar to request.getSession().invalidate();
If there is a load balance configuration, will must have to configurate a route in the network for preserve the requests in the same server. Otherwise, the each request will go to a different server, losing the session attribute.
Edit your tomcat context.xml file and replace <Context> tag to <Context useHttpOnly="false"> , this helped me.
Are you connecting via http or https?
For servlets the session I'd cookie has attributes 'secure' and 'httpOnly'. 'secure' means user agent will only send cookie if transport is secure (https/tls). If your connecting with http a new session is created on each request. 'httpOnly' means the cookie can not be modified by client side script.