Chris,
Let me rephrase what I said: I am not using any custom cookies, the
JsessionID cookie gets created by default.
So i created an HttpSessionAttributeListener listener. And what i
observed is truly weird. Once i click on Messages tab, the request
goes through fine, there are a couple of images that are requested
that are delivered correctly. After all this has finished, 2 of the
attributes i have stored in the session are removed. Mind you, i have
more attributes that DON'T get removed. I did a complete hack that IF
these other attributes are still present then go ahead and put the 2
attributes back into the session - and it works fine now!
Of course i'm not gonna leave it like this, i still need to figure out
what the hell is going on! Here is my filter code:
public void doFilter(ServletRequest request, ServletResponse
response, FilterChain chain) throws IOException, ServletException {
boolean authorized = false;
HttpServletRequest req = (HttpServletRequest)request;
HttpServletResponse res = (HttpServletResponse)response;
HttpSession session = req.getSession(false);
System.out.println(req.getRequestURL());
if (session != null && session.getAttribute("ub") != null)) {
authorized = true;
System.out.println("setting authorized = true");
chain.doFilter(request, response);
}
// forward the request to login page
if (!authorized) {
System.out.println("kicked someone from
"+request.getRemoteAddr());
res.setHeader("session", "invalid");
res.sendError(HttpServletResponse.SC_UNAUTHORIZED,
"Your session is
invalid or have expired.");
}
}
-h
On Wed, Aug 25, 2010 at 10:11 AM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hisham,
>
> On 8/25/2010 9:55 AM, Hisham wrote:
>>> 1. Are you using cookies? If you don't properly encode all the URLs in
>>> your webapp, you could be losing session information when cookies are
>>> /not/ being used. It sounds like you are using cookies, though, given
>>> your statement about using Firebug to read the headers en route.
>>
>> I'm not using any cookies. Also i want to stress the fact that the
>> app works fine in my local environment.
>
> Uh, then I'm confused by your original post, which included this:
>
> "
> Which is strange because the session id is
> the same (i have verified by printing it out, and also seeing what is
> sent in the actual request headers via firebug).
> "
>
> If you were observing the headers for your session id, then what other
> header would you be looking for besides the JSESSIONID cookie? IF you
> aren't using cookies for session id management, then are you properly
> encoding all your URLs? If you aren't, you'll lose your session when you
> click on one of those URLs.
>
> Please post the HTML code around the link to your "Messages" page.
>
>>> 2. Even if your session id is okay, are you dumping the value of the
>>> "test attribute" for the session? Even though you aren't removing it,
>>> that attribute might have been damaged by something else.
>>
>> I've looked everywhere, and unless i missed something i don't think
>> this is the issue.
>
> You still didn't say that you actually observed the value you expect to
> be in the session, and your Filter still forces a login. Could you:
>
> 1. Post the code to your filter
> 2. Add a logging statement that prints the URL being accessed
>
> It's possible that there's some image being requested that's fouling
> things up.
>
>>> 3. You could write another filter that wraps your HttpSession when
>>> requested by the webapp and reports all modifications to it (that is,
>>> calls to setAttribute/removeAttribute/setValue/removeValue).
>>
>> How would I go about doing this? Is there a particular filter that
>> listens to attributes being changed?
>
> No, which is why I said you could write one. I believe I've posted the
> full code for such a filter on this list in the past. Consider searching
> the archives.
>
>>> 4. Any reason not to use the container-managed login and session
>>> management? Tomcat can take care of all this logic for you...
>>
>> Will eventually move to this, you're right. I am using Spring so will
>> use Spring security/Acegi.
>
> Maybe now would be a good time for that. You may spend less time
> implementing ACEGI than you would tracking-down whatever this problem is.
>
> I suspect that the Windows vs. Linux environment is not related to the
> problem you're experiencing (unless this is some kind of case-sensitive
> issue, which is entirely possible).
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkx1JIsACgkQ9CaO5/Lv0PBfpwCcCjb7uWXkbMTqy8JAbFcshZBA
> 1uAAn079qe7eMAQ+KiHojMk/Rx3+jqt0
> =FGiU
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
