> > The reason - it's a huge security hole to not check them ( IMHO ) - a site
> > running multiple webapps ( with different security constraints ) may be
> > compromised if the constraints of the original requests are propagated on
> > forward. ( you can get a request dispatcher for a different webapp - and
> > then call include for a "secure" page ). Disabling access to other webapps
> > is not allways possible or a good idea.
> >
> > Of course, in 2.3 that seems to be required by the spec - I just hope I'm
> > wrong and there is a way to avoid the security hole.
>
> 2.3 assumes that security is handled at the web app level, by restricting
> access to RDs for another app. This is also in the 2.1 spec. I'm not sure
> I understand why you think that's "not always possible or a good idea."
I think 2.2 doesn't assume that ( and at the time the implementation was
written, there was no 2.3 ). Plus the previous code seemed to work that
way.
I said it's not always possible because Tomcat3.2 doesn't implement any
restrictions on ServletContext.getContext() - it's on the todo list, but
we need a way to express what apps can access other apps, and that's not
defined ( AFAIK ).
Also, most servers ( Apache, etc ) seem to do a full processRequest for
internal redirects - that include authentication/authorization - and again
we'll make even harder to integrate web servers with the servlet api.
Anyway - it's not a big deal, in 3.3 we'll have to implement restrictions
on ServletContext.getContext() and that'll resolve the problem, and 3.2
doesn't claim to be able to run multiple security domains ( it can run
untrusted apps, but can't isolate one app from another - the 3.2 core is
still not there ).
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
