In J2EE web application, how do I disable the default HttpSession creation?
We have our own way of tracking session, we don't use default jsp/servlet session but the default session sets cookie in browser which I would like to avoid. Right now on every JSP page we specify as session="false" in page directive but often some developers missing this part, so I am trying to find a common place where I can control default session.
I am trying to find a common place where I can control default session.
The answer is servletcontainer specific since that's the one responsible for session creation and management. The standard Servlet API isn't responsible for that. It's unclear which servletcontainer you you're using, so here's a Tomcat targeted answer: create your own <Manager>.
Alternatively, you can also entirely disable cookie support and rely on URL rewriting only (but not do it). This way sessions won't survive among requests. You can do this in in for example Tomcat by setting the cookie attribute of the <Context> element to false.
If you're using another servletcontainer, then you need to consult its documentation based on the newly learnt information and keywords here above, or just to mention here which one it is.
Related
In a webapp I'm using several filters and in one of the filter I'm using something that BalusC described as "session abuse". Basically in the Filter I do something like this:
request.getSession().setAttribute("abuse", ...);
while, later on, in a Servlet, I read back this attribute.
I'm using a session attribute instead a request attribute because I'm doing a redirect and that's where I'm lost...
After the browser receives the 302 and does the redirection, how does Tomcat (or any other Java webapp server) knows that the subsequent GET (the one after the redirect) belongs to the same "session" as the session returned while inside the first Filter (the one before the redirection took place)?
Does this work even if the client's browser has both JavaScript and Cookies turned off AND if I'm disabling JSESSIONID?
I should point out that JSESSIONID is disabled for SEO and for user-friendliness purposes: just like stackoverflow.com does never show super long URLs with pointless technobabbles in them, my webapp doesn't either while JavaScript and Cookies could be turned off by the user. So I want to know if the "session abuse" I'm doing would be working even if these three "client-side features" are not available.
If you have cookies disabled and url rewriting disabled, then the Servlet container cannot track sessions. Actually I think a few still can using SSL - there's a session tracking built into SSL, but I am not sure many servlet containers support this methodology and it requires pure SSL.
If you don't track sessions, then each session gets created and then orphaned.
The Servlet API resorts to URL rewriting if cookies are disabled.. and every URL that we provide in our JSPs must be inside c:url for this to be in effect. But, in Struts 2, there is an equivalent tag s:url, but its documentation says nothing about automatically adding url-rewriting information (if required) to the url. Is its behaviour similar in this regards to c:url, or do we have some other means to achieve the same effect in Struts 2 ?
I am using Struts 2.1 url tag reference from here
Clarification : In case that the user disables cookies, the other option is to append the jseesionid to each url that is there on the page. c:url handles that for us. My question is that whether s:url does the same thing for us. I was worried as its not mentioned in the documentation link I provided above.
Yes struts2 will do this too. Simply disable cookies and you should see a session id is put into the url (when using s:a tags, I have not tested url tags). I'm glad you added clarification because this is url writing. Url rewriting is done as urls come into the server, where they are then rewritten by certain rules generally so they get directed to the right place within the server(which is not at all what is happening here).
Edit: Thanks to Daud, the correct term is url-rewiting. This is because session management is handled by the container level, although struts2 can manipulate what the session contains, it is the container which provides the session via a "session manager" object and determines how persistence is best managed (including generating the jSession Id).
For details on this for glassfish: http://docs.oracle.com/cd/E18930_01/html/821-2418/beaha.html#beahf
For details on this for tomcat: http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Disable_Session_Persistence
For other containers simply google: Container_Name + "session manager"
I have a java web application. When I log in to that application and navigate to a jsp which has flex chart embeded into it, the chart displayes just fine. I am using blaze ds remoting object mechanism. But when I want to navigate to a different page, it logs me out of application since the login session is lost.
The HTTP session is backed by a HTTP cookie which is tied to a specific domain and by default also the context path. So if you lose the session, then it may be caused by navigating to a different domain and/or context path. It's however also possible to invalidate the session programmatically by calling HttpSession#invalidate().
So to fix your problem, you need to ensure that you're navigating to a page in the same domain and context and that your server side code is not unnecessarily calling invalidate() somewhere.
If the problem is actually caused by a switch in the context path and you'd like to get it fixed, then you need to configure it in the servletcontainer. It's unclear which one you're using, but in for example Apache Tomcat you would like to set the emptySessionPath attribute of the <Connector> element in /conf/server.xml to true. Also see this document.
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...
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.
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" %>
...
link1
link2
...
<form action="<c:url value="servlet" />" method="post">
...
</form>
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.
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)
If cookies are disabled, most session providers append a URL parameter called JSESSIONID to maintain session state
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.
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.
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.
I need to prevent Session Fixation, a particular type of session hijacking, in a Java web application running in JBoss. However, it appears that the standard idiom doesn't work in JBoss. Can this be worked around?
This defect (found here) points the way to the solution. The Tomcat instance that runs in JBoss is configured with emptySessionPath="true", rather than "false", which is the default. This can be modified in .../deploy/jboss-web.deployer/server.xml; both the HTTP and AJP connectors have this option.
The feature itself is used to eliminate the context path (eg. "foo" in http://example.com/foo) from being included in the JSESSIONID cookie. Setting it to false will break applications that rely on cross-application authentication, which includes stuff built using some portal frameworks. It didn't negatively affect the application in question, however.
This problem and the specific case in which it occurs is a problem in Tomcat as well as JBoss. Tomcat shares the emptySessionPath="true" effect (and actually JBoss inherits it from Tomcat).
This really seems like a bug in Tomcat and JBoss when you are trying to prevent session fixation attacks but the servlet spec (at least version 2.3) does not actually require the JSESSIONID to be defined or redefined according to any specific logic. Perhaps this has been cleaned up in later versions.
One workaround is to store the client address in the session. A response wrapper should validate the client address set in the session is same as the one accessing the session.
I came to know below code setting snippet from one of the forum. And I added below lines. But when I print the session ID after and before log in into the application it is same. How would I test session Fixation.
D:\jboss-5.1.0.GA\bin\run.cof file and add the below line.
set "JAVA_OPTS=%JAVA_OPTS% -Dorg.apache.catalina.connector.Request.SESSION_ID_CHECK=false"
in each context.xml of the jboss applications.
D:\jboss-5.1.0.GA\server\default\deploy\jbossweb.sar\context.xml