On 27/08/2010 18:16, Hisham wrote: > Hi Chris, sorry for the late reply > > 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.
Thread.dumpStack();
p
> This would be very useful, but how would i generate it since theres no
> exception that's been thrown? Do i just throw an exception?
>
> -h
>
>
>
> On Wed, Aug 25, 2010 at 2:50 PM, Christopher Schultz
> <ch...@christopherschultz.net> wrote:
> 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
>>
---------------------------------------------------------------------
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
0x62590808.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
