-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hisham,
On 8/25/2010 11:07 AM, Hisham wrote:
> Let me rephrase what I said: I am not using any custom cookies, the
> JsessionID cookie gets created by default.
That makes a lot more sense.
> 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!
Er, that will sort of subvert your own authorization mechanism, right?
In your listener, why don't you dump a stack trace when a session
attribute is removed? That will let you know where the code is that is
removing your attributes. You may be surprised.
> 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.");
> }
> }
Aside from the odd logic above, this looks okay, except, I don't see a
redirect to a login form anywhere, here. You also didn't say what the
URL mapping was for this filter was. Is it "/*"? If so, then you'll
probably not be able to serve your login page unless you're logged-in.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkx1Zg8ACgkQ9CaO5/Lv0PA6HACcDuDEppOaVSyuDrvYqjB68uD5
Em4AnjyHmIRgcO5ncOAV22CkAPOy18Vp
=SOPc
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
