So I went through the steps to build a basic roo application here: http://static.springsource.org/spring-roo/reference/html/beginning.html
I started up my server and started playing with the app, couldn't help but notice that there's a 'jsessionid' in my url:
http://localhost:8080/pizzashop/pizzas;jsessionid=0A8EA5D9E8665C8AC80F141C3818F6BA?form
I don't care for this at all! Why does it need a session id in the URL? Can I get rid of this? It does not seem RESTful to have this there.
This is standard JavaEE behavior, and is dictated and controlled by the servlet container. It has nothing to do with Spring.
See this previous question to find out why and when it gets created, and how to avoid it.
I didn't see this answer in the other question so I wanted to explain it. The way sessions work in java and I think php, is when the client first comes it, it creates a cookie and appends JESSIONID to all the urls that used <c:url/> tag. The reason it does this is because the first time the client visits the page, the server has no idea if the client supports cookies. So it does both. Next time, since it sees the cookie, it will actually not use URLs anymore because it knows cookies worked.
There is a lot of ways to disable this. If you are not using sessions at all then you can disable cookies by putting cookies=false in context.xml. This only disables cookies for the session and not regular cookies. You can then use urlrewrite to stip the sessionid.
Hope that helps.
What app server are you using? I know that Weblogic at least will always do a URL encoded session, as well as a cookie based session, on the first call at least, to see if cookies are enabled on the client. If it can't find the cookie that matches the URL session id on the next call, it will continue using the session token from the URL. I know when they switched our company over to using Sharepoint for web crawling and search the windows web guys whined for a LONG time about the issue, until they finally understood that all they had to do was turn on cookie session support.
In my case this was happening when the application was deployed on my desktop and not using https. In which case in weblogic.xml, cookie-secure should be set to false. Otherwise cookie managed session ID will only work over https.
<wls:cookie-secure>false</wls:cookie-secure>
Related
The Problem
When redirecting from a servlet using response.sendRedirect(redirect_url);, the JSESSIONID cookie is not passed by the browser to the destination. A new JSESSIONID is created for every redirect, and it is impossible to track the user.
Note: This problem is only occurring on my new server implementing https and a domain name; the session ID is properly tracked when I run the web app locally or on another server without SSL or a domain name. Edit: I have set up another site on my server without SSL, and the issue persists. This seems to narrow the issue down to having a reverse proxy Apache.
An Example
The Login servlet on my web app attempts to store the user information in a session attribute then redirects to the MyCards servlet. I am using a redirect so that the URL will display mydomain.com/MyCards instead of mydomain.com/Login. The MyCards servlet attemtps to access the session attribute but finds nothing, and therefore redirects back to the Login servlet. This worked perfectly before deploying the project on my new server with SSL and domain name.
My Setup
Ubuntu 20.04 on DigitalOcean droplet
Apache Web Server (apache2) ... I have enabled mod_sessions, not sure if that's relevant.
Tomcat 9
Reverse proxy in Apache VirtualHost to Tomcat (I can post my .conf file if requested)
A redirect in Apache VirtualHost from HTTP to HTTPS
JDK 11
Possible Solutions
Using a forward instead of a redirect. The session ID is not lost when using requestDispatcher.forward(request, response);. As I mentioned above, I want the URL to reflect the destination for an intuitive user experience, which does not occur when using a forward.
Implementing your own session cookie, as in this answer, and manually storing sessions with a map, as in this answer, which strongly advises against such a facility. Based on my understanding, doing so poses security threats to user data. Also, if the browser is not passing the JSESSIONID cookie, I don't understand why it would choose to pass the manually implemented cookie unless the SameSite attribute is set to None (also bad).
Verifying that the webapp's context.xml does not have cookies="false" configured. Done that.
Using encoded URLs with response.sendRedirect(response.encodeRedirectURL(url));. Again, for the sake of having a clean URL (which the user could bookmark or type in) is preferable, and encoding the session ID into the URL is not.
Using relative URLs instead of absolute URLs...
"A session is only maintained if the redirection is being sent on the same port, host and webapp [and protocol?]. If redirection is done within the same application, using relative paths is the best practice." I tried both redirect_url = "/MyCards" and redirect_url = "MyCards", no luck.
Possible Reasons
Perhaps I am unknowingly switching between HTTP and HTTPS, which is a change in protocol and will not preserve the session ID. Of course, my intention is to remain secure and stay exclusively in HTTPS. Edit: I have set up another site on my server without SSL, and the issue persists. This seems to narrow the issue down to having a reverse proxy Apache. When accessing the web app directly on Tomcat (i.e. with <server_ip>:8080/MyWebApp), the session is tracked properly on redirect. However when using mydomain.com, the session ID is lost on every redirect.
Something to do with naked domains.
Other?
Edit: Maybe the issue is occurring because of the way the client, Apache, and Tomcat interact via the reverse proxy. Does the proxy cause the domain/port to change on every request/response?
My Questions
Why exactly is the session ID lost when using a redirect to a relative URL to a servlet in the same web app on the same server? Shouldn't the redirect occur entirely on the server-side, preventing a new request/session from being created? Since the relative URLs (which I thought would preserve the session) did not solve the issue, does this indicate some problem with my server setup (e.g. unintentional switching between protocols)?
What is the best practice for maintaining the user session ID, even when the user has cookies disabled? Is there no way around URL encoding when cookies are disabled? Or should the app be implemented exclusively with forwards rather than redirects? If so, is there a workaround to changing the URL to reflect the destination?
Note: this is my first post, so I don't have the reputation to comment. I will edit the post with any needed information.
I have a problem with cookies handling using java:
we have a tomcat cluster managed by apache to serve multi application, all on the same domain.
First problem:
Creating cookies using java, setting the cookie.setPath("/") to cover all domain pages, in order for all applications to be able to read the cookie, the scenario,
i'm in application1, app1 creates the cookie, setting the path of cookie, to the /app1/
moving to app2, app2 can't read the cookie, it creates the cookie with another path, /app2/
what is going wrong with ?
Second problem:
The perfect code for cookie deletion works fine with me, on our servers,
but moving out to different servers, the code can read the cookie, so no domain problem there, but can't delete it.
Again what is going wrong with java handling cookie ?
Do i have to use javascript better than java for cookies handling ?
You should set the domain, not the path:
cookie.setDomain("example.com");
Now all applications hosted on example.com will be able to share the same cookie. For example applications on app1.example.com and app2.example.com will be able to see this cookie.
i want to login into an web-application and want to perform some search operation after login. I am using httpclient for this and i am able to login and fetching the data of that page but i didn't get anyway to perform post operation say searching of any user account after login. As it is asking for login again. Please provide any way or idea to do this?
When you login into a site the server usually sends you back a cookie containing your session id, or the jsessionid header. Try sending this jsessionid and its value back to the server in the post-login operation.
This may not work, because the server can force you to use cookies. This is just an idea of the scenario often found around there.
Its not httpclient, but there is a browser automatization framework called selenium.
look here for an explanation how to use cookies in java, using the java.net APIs http://www.hccp.org/java-net-cookie-how-to.html
I have had a scoping issue with a session cookie not being visible in the past. You "may" have the same issue.If you know the session cookie is being created after you have logged in successfully, try adding a call to setDomainMatchingStrict(false)
import com.meterware.httpunit.cookies.CookieProperties;
WebConversation wc = new WebConversation();
CookieProperties.setDomainMatchingStrict(false); // <- the important bit
I am having problems in Java while managing sessions. All works perfect(I create and get/set values in the session), until I redirect with a link (the link is in a JSP). Then, the session is lost.
My server is Tomcat, and my browser is a Firefox browser. I am using Struts 2.
Thanks for your time ;-)
The standard time for the session to automatically get erased is about 30 minutes (for example in Tomcat), but it depends on the configuration.
If you write session.invalidate(), your session gets erased too.
Your session gets automatically lost if you close every tab in the browser you opened the session (even is you have other windows with the same browser).
Is your link inside the same application server? If it does, it shouldn't get lost if you are not doing things I said before.
If you accept cookies in your navigator, your code may call invalidate() when you go on this page. Check filters too.
One possibility is that your current session cookie is marked as "secure", and the 'href' is an "http:" link. This will cause the browser to not send the cookie, and depending on your webapp structure a new session may then be created automatically.
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.