We Keep Coding

Is there some way to delete session info from address line when redirecting?

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.

set session cookie secure and httpOnly for LFR_SESSION_STATE_%

Environment :
Liferay 6.2 with Jboss
We are trying to implement httponly and secure.
For this we have dome some changes like below
Added in Portal-ext.properties :
cookie.http.only.names.excludes=
and
Added following properties in ROOT.war/WEB-INF/web.xml
<session-config>
<cookie-config>
<http-only>true</http-only>
<secure>true</secure>
</cookie-config>
</session-config>
I can see all the session cookies are httponly except the one which are starting with LFR_SESSION_STATE_
Can anyone suggest how we can handle this.

LFR_SESSION_STATE_ are cookies that explicitly get handled on client-side and not on server side - thus they're inherently only accessed through JS. As far as I know they're never even persisted on server side. And I don't expect any real leakage from these cookies. In my perception the cookies are about determining state of the quality "should this help item be shown with full text or just collapsed".

Java EE / Struts persistent sessions

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

What is the mechanism by which a session attribute passes from a filter to a servlet?

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.

What is empty session path in tomcat?

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>