tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Curwen" <>
Subject RE: FORM Login Bypassed
Date Fri, 01 Aug 2003 18:38:38 GMT
comments inline.

> -----Original Message-----
> From: Tim Funk [] 
> Sent: Friday, August 01, 2003 1:32 PM
> To: Tomcat Users List
> Subject: Re: FORM Login Bypassed
> 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." ===

Thanks Tim, for covering my laziness today. I'd normally look through
the spec, but thought I'd leave it for someone else. ;)

> 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 

But what if you have a confederation (hmm... $20 word for the day) of
components that all together act as your controller.  One main traffic
cop controller out front that will invoke appropriate business logic in
other controllers... those *other* controllers having the security
constraints. More on that in my next comment.

> Adding a constraint to the incoming URL is not a big deal if 
> one knows this constraint before coding a webapp. 

But what about the case where the incoming URL is facading any number of
requests for resources?  It's almost as though you shouldn't ever
consider doing what Ronnie is doing (one monolithic traffic cop out
front) because you can't protect access to a subset of resources, or
have different users set up for different resources, etc, etc.  Is it an
acceptable work-around to use sendRedirect() or is there a better
pattern or 'best practice' recommendation? 

View raw message