tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Funk <>
Subject Re: FORM Login Bypassed
Date Fri, 01 Aug 2003 18:31:34 GMT
Security constraints are imposed on the incoming *client* request and does 
not apply for forwards and includes. This is true for 2.3 and 2.4 is stated 
in "SRV.12.2 Declarative Security"
"The security model does not apply when a servlet uses the RequestDispatcher 
to invoke a static resource or servlet using a forward or an include."

I don't think its possible to impose auth constraints for includes, it would 
contradict the spec. Since includes cannot set headers and host of other 
things, allowing this for authentication would be a PITA for implementors and 
break in many circumstances.

Adding constraints on forwards could be feasible but I don't like it (IMO, 
YMMV) since in an MVC style, your controller could go through a lot of work 
to set up the model only have the view deny access. This could cause a lot of 
confusion for developers.

Adding a constraint to the incoming URL is not a big deal if one knows this 
constraint before coding a webapp. But discovering this constraint after the 
webapp was created can make life miserable.


Mike Curwen wrote:
> But that's not quite the situation here...
> It's still a request for a resource
> 1.  request /dispatcher?page=fookey
> 2.  dispatcher translates fookey to /somepage/somewhere.jsp
> 3.  a request for /somepage/somewhere.jsp is made
> 4.  somepage/somewhere.jsp has a security constraint not being honoured.
> And this is because security constraints are only checked for
> client-side requests, and not through forwarded or included requests
> (serverside). Filters currently act this way (the filter mappings are
> not honoured when server-side requests are made).  
> Do you (or anyone else) think that AUTH mappings should be 'enhanced' as
> well, so that forwards/includes will be checked? (like Filters have
> changed for 2.4) 

View raw message