[EMAIL PROTECTED] wrote:
>
> > There lies the catch and the source of problem in my understanding.
> > In different requests relating to
> > the same session, I may get referance to HttpSessionFacade instances which
> > are different, but I expect them to be same (although not guarantied by
> > specs but I thought it was a tacit agreement between container and servlet
> > developer). What I suggest is that tomcat should recycle the
> > HttpSessionFacade instance only when the HttpSession instance is
> > recycled.This might be more inefficient as it will result in N instances on
>
> You are right, I know what's the problem. It's not hard to fix, but this
> week I have no time ( and probably neither next week ), but this bug has
> been on my list.
>
> In fact, there is a larger problem here - with very serious security
> and performance implications.
>
> To get decent performance you need to recycle ( the cost of allocating
> few hundred objects per request is huge - it means the server will
> saturate on even small loads). Most servlet containers do recycle - the
> problem is common to all of them.
>
> Unfortunately recycling opens a security hole: a (bad) servlet may keep
> reference to the HttpServletRequest, HttpServletResponse and HttpSession
> objects - and later access the them. That means it'll be able to access
> data in a HttpServletRequest that is in use by another servlet, in another
> application.
>
> We have most of the elements to fix this hole - and with a decent ( small)
> perfomance hit. We need to make sure that a servlet receive only facades
> that are local to it's context. That's easy to do by either maintaining a
> per/context pool of facades or just doing nothing ( since the facade is
> very "light").
>
> There is nothing that can be done with the original Request (and I don't
> know any possible fix for this problem in containers that don't use
> facades ) - you know the context after you process the request, and then
> you've already allocated the request. It may be possible to process the
> request line before allocating the request - but that's ugly. Anyway,
> that's not a problem in 3.x.
>
> Regarding HttpSessionFacade - you are right, ServerSession should have a
> get/setFacade and all getSession() calls should return the same
> facade. 1/2 of that is done in 3.3, I just need to do one more change -
> it's easy to duplicate this in 3.2 also. Of course, when the session is
> invalidated the facade must be either saved in a context-specific pool or
> just let it die.
Another solution, IMHO, is to make sure all these objects are only used
within the thread they where allocated for. Briefly, add a package scope
setThreadID() method to the classes that implement pooled objects like
this and let the container call this method with the current thread ID
before it delivers the object to the application. Then compare the
current
thread ID with the assigned thread ID in all methods the application can
call. If they are not the same, throw IllegalStateException.
Again, the spec is not clear on this. Maybe it needs to be clarified
with regards to how the container-objects can be used by the application
(some attempts to clarify this is being added to the JSP 1.2 spec with
regards to tag handler classes).
Hans
--
Hans Bergsten [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
