tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid <...@pidster.com>
Subject Re: Session problem
Date Fri, 27 Aug 2010 17:19:49 GMT
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
> <chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>

> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org



Mime
View raw message