comments inline. > -----Original Message----- > From: Tim Funk [mailto:[EMAIL PROTECTED] > 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? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
