In your cases there is nothing preventing you from programmatic security.
I look at security the same way some db verndors do. I might not have access to any table, but I might be granted access to a table or view which may access those tables I am not allowed to directly see.
In the case of a monolithic traffic cop, that can still be fine depending on your architecture. In fact, I hope to do something similar where I have one apache instance with jk or mod_proxy installed and it farms out *all* requests to different tomcats depending on the URL namespace(directory). Then apache can handle SSL and any other decorators and each tomcat can perform additional constraints (container or programmatic) as needed.
If you are rewriting URL's on the fly - this usually is a recipe for pain in dev vs test vs production.
-Tim
Mike Curwen wrote:
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]
