I'm using Tomcat 7.0.84, and my web app uses the Servlet 3.0 deployment descriptor. The web.xml file contains this:
<session-config>
<cookie-config>
<name>JSESSIONID</name>
<http-only>false</http-only>
</cookie-config>
<tracking-mode>URL</tracking-mode>
<tracking-mode>COOKIE</tracking-mode>
</session-config>
I have a desktop application that logs into the web app and establishes a session. In response to a user action, it invokes a URL in a browser. Since I want the browser to be logged in with the same session, I append the jsessionid path parameter like this:
http://server/contextroot/path/;jsessionid=8BDF744802E7850D5AA4AB6535163504
I close my browser completely so when the URL is spawned, no previous session cookies will be sent. (My default browser is chrome, and I verify this is the case.)
I also very in code that the URL tracking mode is enabled, by logging the return value of
ServletContext.getEffectiveSessionTrackingModes.
What I'm expecting is the browser request to automatically get the session indicated by the ;jsessionid parameter, but it is not happening. Each time Tomcat includes a new session cookie in its response.
This code used to work with a previous version of Tomcat (Probably 5.5) and the servlet 2.3 spec. I don't see anything in the Servlet 3.0 spec or Tomcat docs that indicate that this shouldn't work, and I'm all out of ideas.
Does anyone know why this isn't working as expected?
Here is how I got this to work:
In web.xml, I changed
<cookie-config>
<name>JSESSIONID</name>
<http-only>false</http-only>
</cookie-config>
to:
<cookie-config>
<name>jsessionid</name>
<http-only>false</http-only>
</cookie-config>
so that the session cookie name is now all lowercase, and exactly matches the name of the jsessionid path parameter.
Another way it worked was to change the path parameter name from jsessionid to JSESSIONID. This is because, in Tomcat, if you explictly configure a name for the session cookie, it uses that as the name of the path parameter used to pass in a session ID. This seems to be out of compliance with section 7.1.3 of the Servlet 3.0 spec, which says:
The session ID must be encoded as a path parameter in the URL string.
The name of the parameter must be jsessionid. Here is an example of a
URL containing encoded path information:
http://www.myserver.com/catalog/index.html;jsessionid=1234
However, it does comply with this excerpt from section 7.1.1:
If a web application configures a custom name for its session tracking
cookies, the same custom name will also be used as the name of the URI
parameter if the session id is encoded in the URL (provided that URL
rewriting has been enabled).
Related
I am using Wildfly, Spring MVC in my project.
And after redirecting to another page of my project - to my browser address line appears some session info like in this image:
p.s. When i were using Tomcat - there was no such problems.
Is there an optimal way to stop auto-adding session information in the address bar?
Thanks.
Update:
In the normal situation, when i were redirecting in my past projects(for example) from page "index" to page "login" i saw something like this: "myapp.com/login"
But now i saw:"myapp.com/login;jsessionid=nGTE5tfW3hUZZOP1yQTF4Mrh3PRbNu8UyY8UBkmx.coderunit".
I didn't made some special options to my app server to cancel this session info additions. Maybe there are some special tool for it.
I solved this problem.
There is some spectial option for web.xml.
This is the default behavior of a servlet container. If the client doesn’t include a cookie in the first request, the container cannot tell whether the client supports cookies or not. Therefore the container embeds the session id in the URL.
You can disable this in your web.xml using the session-config element:
<session-config>
<tracking-mode>COOKIE</tracking-mode>
</session-config>
It helped me. Good luck.
I am using spring security login mechanism for my application and tested everything.Things were working fine.I have the following use case
If customer is not logged in , application will redirect customer to the login page.
On successful login, application will redirect customer back to same page from where they were redirected to the login page
this is the Java code used to redirect user to his original location
final SavedRequest savedRequest = this.requestCache.getRequest(request, response);
targetUrl = savedRequest.getRedirectUrl();
getRedirectStrategy().sendRedirect(request, response, targetUrl);
RedirectionStrategy being used here is DefaultRedirectStrategy, things were working fine. Application is now deployed on the Pre Production server and now this seems not working and I am getting 404 error.
When customer is being redirected to the home page,targetUrl is coming out as "/", I have a Spring controller named with this mapping
#RequestMapping("/")
public class HomePageController{ // home page code }
my application's current Pre-Prod urs is prepd-www.mysite.com so when sendredirect come in to action, webpage URL is getting changed to prepd-www.mysite.com/prepd-www.mysite.com
I am not sure what is causing this issue. is it because of the proxy server settings ?
Can any one suggest me about the possible root cause of this issue?
I have already tried it on all local machines and well on our QA but everything is working perfectly fine.
Current setup for the environment where this is happening is
We have 4 app server
We have one load balancer which is redirecting traffic to one of the app server.
Just a wild guess since you could not give the reverse proxy configuration, nor the exact URL used in pre prod and in developpement.
You say you are using DefaultRedirectStrategy from Spring security. This strategy has an option (contextRelative) that prepends the ServletContext path to the URL. If in your developpement system you were using the root context, that is if you were accessing home page at (for example) : http://localhost:8080/ the serlet context was empty.
But if now in preprod, the servlet context is no longer root but is say /myApp once translated by apache reverse proxy, when you redirect you get an URL of /myApp/myApp that could be translated back to what you gave.
You could try to control whether you have contextRelative as true in DefaultRedirectStrategy and if yes if you can set if to false and also control if you redirect to absolute or relative URLs.
If you are using apache in front check rewrite rule and redirect rules of apache config. Best way would be to ssh tunnel directly to application server(by skipping apache) and test. If it's working that means your application config is fine and it needs to be fixed in apache.
Are you using in preproduction tomcat or another application server?, normally if your war is calling foo and your commit to tomcat, the path for this war is
http://localhost:8080/foo/
So if you are using servlet you need specify in your web.xml that the main path is foo/*
By default Tomcat uses the web application name (context path) as the session cookie path when it generates a session cookie. Is there a way to influence this programmatically? I'd like to include a subset of the servlet path. (This is for a multi-tenant web application where a user can be logged in to more than one tenant at a time, in different windows.) I don't want to set it to a fixed string in a configuration file.
I'm doing my first Java EE web application and I'm struggling with sessions.
in my web.xml file I put the following settings:
<session-config>
<session-timeout>30</session-timeout>
</session-config>
But if I close my browser which is not configured to delete cookies on close,
after reopen the session is over.
How can I have a "persistent" session ?
check if a cookie named Jsessionid is getting created during your first request. And close your browser open it again and check if that cookie is still there and value is same.
I think it will not be, and that is the reason your session expires.
When a cookie's expiration is set to "session", it will get deleted by the browser when the user closes the browser. This has nothinng to do with the web.xml session-timeout setting, which will force-close the Java EE session server-side if there are no requests by the user in the designated timespan.
Spring has "remember me" functionality:
http://static.springsource.org/spring-security/site/docs/3.0.x/reference/remember-me.html
I have read apache tomcat documentation a day before, and I am so confused about emptySessionPath . Up to my knowledge, if it's set to true, the emptySessionPath is stored at the root folder of web application. Please give the right definition of the term emptySessionPath and what happens if it is set to true and false?
Please guide me.Thanks in advance.
The emptySessionPath field just states whether the all cookie should be stored in the root URL path / (if emptySessionPath=true) or not (otherwise).
This is used by Apache's Connector. See details here (This is for AJP Connector, which is part of the Connnector object).
What this basically means is:
If emptySessionPath is enabled in
tomcat, the JSESSIONID cookie is
written to the root "/" path. This
means that whatever webapp you are on
will use the same cookie. Each webapp
will re-write the cookie's value to
hold that webapp's session id, and
they are all different.
When this is enabled and servlets in
different webapps are used, requests
from the same user to different
servlets will end up overwriting the
cookie so that when the servlet is
again interacted with it will create
a new session and loose the session it
had already set up.
If emptySessionPath is not set, there
are multiple cookies in the browser,
one for each webapp (none at the
root), so different webapps are not
re-writing each other's cookie as
above.
JSESSIONID is the ID Session for your Webapp. See a full explanation here.
Update: This information about usage is somewhat outdated - see here for a more up-to-date information on how to set the Session path also for recent tomcat.
If emptySessionPath is set to true, it will eliminate the context path from JSESSIONID cookie.It will set a cookie path to /.This attribute can be used for cross application autehentication mechanism.
Session are, as you probably know, often maintained by a cookie. A cookie has two values that determines whether they should be returned by the browser for a certain request, cookieDomain and cookiePath. The cookiePath must match that of the request.
A request is made for
/some/request/for/this.html
Cookie would be returned with cookie path:
/
/some
/some/request
But not for cookie path:
/other
By spec, a session is not shared between different web applications, so if you have web application foo.war deployed under /foo, the session cookie path would, by default be set to /foo.
It seems Connector.emptySessionPath is a protected variable on Connector. I haven't read the code - but I guess it has something to do with Tomcat's single sign on or sharing sessions, where you login to one context and are authenticated in all - in which case the cookie path must be / for the session cookies.
Just in case, for the web_app version 3.0, the cookie configuration is standarized, so the equivalent to the AJP's emptySessionPath in webapp 3.0 is:
<session-config>
<cookie-config>
<path>/</path>
<secure>true</secure>
</cookie-config>
</session-config>