On 7/2/01 1:14 AM, "Scott Eade" <[EMAIL PROTECTED]> wrote:
> Velocity question but I'm using tdk...
>
>
> I like the fact that this approach detaches the
> permission checking for the screen template from
> the screen classes, but I am cautious because it
> makes it so easy for someone with access to the
> templates to get around the security. What do
> you think about this approach?
I think it's awful. The security of your system should
have absolutely nothing to do with your templates, even
in macros. I know that in 2.1 it is cumbersome to have a site
with complex security requirements so maybe you have to
resort to what you are doing.
In 2.2 there will be a policy service where the security attributes
for a particular part of your site can be configured (with an xml file,
or properties, or a database). This way there would simply have to be
one type of screen for security and you would have to subclass
security screens and override isAuthorized for each different part
of your site. I'm also hoping that this role/perm attribute tree
that is analagous to your site will behave like an inheritance
hierarchy so that if a particular screen has no permission settings,
a mechanism can wander up the security attribute tree until it finds
the first parent node with security settings and use those. So you
will be able to set base permissions and override where you want
to change things. I have a simple policy service working now but I
trying to make a better tree structure (borrowing from xerces) that
makes it fast at looking up attributes in parent nodes.
Do what you have to do but I think having security code of any kind
in the templates totally breaks MVC.
> Scott
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
