We Keep Coding

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.

How to keep URL same for all request

I am working on a website, where I am using Java/Java EE/struts.
When I request any page it shows me session id and all other stuff in URL. Will some one please help me how to get rid of. I am reading about URL rewriting. But I am not getting how to implement it.
Ex.
http://mywebsite.com/welcome.do;jsessionid=6E79E050360BAC1858CA7AC7974D75C7
I want it to be http://mywebsite.com/ only.
This is useful for SEO also.

I suggest you set the canonical URL instead if you are worried about SEO.
http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html

Stripping the session id is useful for security and might be for SEO. Keeping the URL identical for all requests isn't.
You want a search engine to distinguish between the different pages of your site. Also you want people/sites to be able to link to a specific page on your website.

How to make sure a user is still logged in using Java Web

I just want to ask how do I make sure a user is still logged in. If he/she's not, then access to pages is not permissible. See, when logging in a page I use a filter to check if the user exists. I wonder if I could use filters to check if the user is still logged in? Only problem is, I tried but when I type the url directly on the address bar the page still shows, now with null values. How does one do this correctly in Java?

What web framework are you using?
Yes, it is achievable using filters/interceptors in most scenarios, especially plain vanilla web applications. In your case, you most likely did not nullify/invalidate the invalid user, or have not redirected invalid users to another page (login page for example).
If you are using Struts, or Spring, i would highly recommend you looking in the direction of Spring Security (Former ACEGI) or Apache Shiro because chances are although your home-made solution would appear workable, they are not spoof proof.

Set a session variable, isLoggedIn=true, after the user logs in. In the filter, check if the session is null, or the logged in flag is false. If not, redirect to some page saying you must login to continue.

Deploying Struts2 Application without ContextPath

I've got a struts2 application running under a contextpath "/path" on my local tomcat without problems. When I deploy it on a webserver (using a proxy to redirect from "http://www.domain.com" to "myserver:8080/path/") Struts does all kinds of strange things.
First, it includes the context in -tags. That can be turned off by an attribute. But sadly, it also includes the path in the action attributes of my forms, so a login form points to "http://www.domain.com/path/login.action" instead of "http://www.domain.com/login.action" ...
Is there a possibility so somehow change the default context that is added here or turn this off for forms? (I'd like to keep the -tags, only way round seems to be to use default HTML forms.) Thanks in advance!

I found that others also had the problem, but the framework makers don't seem to think that this is an issue. My solutions:
use includeContext="false" in all s:url-tags
instead of the s:form tag, use a usual form, set the action to "actionname.action" and include a simple table with tablerows () for each field. You still can use s:textfield and such.
sadly HTTP sessions won't work anymore as they get set for the path "/path" (the ApplicationPath). This is due to the cookie that saves the JSESSIONID being set to /path. This means that your visitors will only get session variables stored when they're at http://www.domain.com/path/login.action and that those will be lost when they get redirected back to http://www.domain.com/interestingstuff.action ... my solution is a hack that requires setting the JSESSIONID cookie clientside via JavaScript as described here: Struts2: Session Problem (after reverse proxy)
Hope this helps someone ... if you find nicer solutions, please let me know. :-)

Though am answering very late to this question, but I reached this page recently when I was facing the same problem.
The application that I was working upon was appending the context-root viz. 'myContextRoot' to my url on localhost and it was working perfectly there. For eg., as mentioned above the action 'myAction' was becoming
http://localhost:8050/myContextRoot/myAction.action
But the moment I deployed it on a server, it stopped working, then after searching like hell, I found a solution for me. I am deploying an EAR file on glassfish and there we have a file application.xml. In application.xml I had a tag 'context-root' whose value was 'myContextRoot' which I changed to '/' and after that I got my url as on localhost and
Hope it may help :)

how can i do sessions in java if some one disables cookies in my browser?

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.