I'm a new Turbin/Velocity user ... So I'll just jump into my 'dumb'
question.
If you don't do security checks in a template (and yes, I do understand
why you don't want to do it there), how do you do it in the servlet? I'm
looking for a small example if anyone would be kind enough.
Jason van Zyl wrote:
>On 7/2/01 1:00 PM, "John McNally" <[EMAIL PROTECTED]> wrote:
>
>>I do not see why the decision on which content to display based on the
>>user, if left in the template, breaks the MVC pattern. I can see how it
>>might be preferred to break out page level security into centralized
>>control. But page level security is just a special case of the more
>>general access control provided by Turbine.
>>
>
> #if (!$mypull.isAuthorizedGlobal("some_perm"))
> $data.setRedirectURI($link.setAction("LogoutUser").getURI())
> $data.setStatusCode(302)
> #end
>
>I think something like above to control page level security is
>distinctly different than what you have below. I don't think that
>access/restriction of pages is part of the view at all while
>what you have listed below is lending to the view for a particular
>user even though I'm not fond of that either.
>
>The criterion I would use is that what's above would mean zero
>to a designer. But I concede there is a difference between a
>designer and a template engineer. The other criterion I would use
>is that what's above references parts of the internal system
>that may change and are therefore unmaintainable by a designer
>because how are they suppose to know what permissions apply
>to what pages.
>
>>Say the following exists within a set of links providing app navigation
>>
>>#if ($acl.hasPermission("administrate"))
>> <a href="$link.setPage("AdminMenu")">Admin Menu</a>
>>#end
>>
>
>I still don't think this is good either because it again references
>parts of the internal system. Even if it is only the permission name,
>that can still change and the designer/template engineer must consult
>someone as to what that permission should be changed to.
>
>Maybe something like:
>
>#foreach ($link in $user.links)
> <a href="$link.href">$link.name</a>
>#end
>
>So maybe this isn't perfect either but protects against changes
>in permission names and the addition of permissions. So you don't
>have to have 10 #if statements to create links for each menu item
>that pertains to a permission the user has.
>
>
>>Being able to selectively show content on the page is very convenient,
>>how would this be done within MVC?
>>
>
>I totally agree. What I disagree with is references to the internal system
>in templates because you limit the freedom of the designer and I don't
>think it's maintainable.
>
>The people who work on Scarab's templates are more technically savvy than
>the designers I work with. Even the #foreach would throw them for a loop
>(ha!) but the page access thing wouldn't mean a thing to them, and they
>don't want to learn about it which I think is fair.
>
>Maybe bending MVC is more appropriate, I guess it depends a lot on who
>is working on your view and how technically competent they are, or how
>technically compentent they want to be. I'm sure we could go on all day :-)
>
>
>>john mcnally
>>
>>
>>
>>Jason van Zyl wrote:
>>
>>>On 7/2/01 9:16 AM, "Scott Eade" <[EMAIL PROTECTED]> wrote:
>>>
>>>>>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.
>>>>>
>>>>Nah, I was just playing around. I have decided that the use
>>>>of Default screen classes provides for cleaner templates.
>>>>
>>>Yup, I definitely think Default screens are a better option
>>>for 2.1.
>>>
>>>>>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.
>>>>>
>>>>That sounds great. I hesitate to draw an analogy to EJB security
>>>>as I have no EJB experience.
>>>>
>>>It very well may be like EJB security. I still don't know very much
>>>about EJB but I'm getting there :-) I'm sure the usage pattern I would
>>>like to implement has already been done many times.
>>>
>>>>>Do what you have to do but I think having security code of any kind
>>>>>in the templates totally breaks MVC.
>>>>>
>>>>I agree (with hindsight ;-] )
>>>>
>>>>>jvz.
>>>>>
>>>>Thanks,
>>>>
>>>>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]
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
--
Edward Muller
Director of Information Services
LearningPatterns.com Inc.
Direct: 212-487-9064 x 115
Fax: 212-202-3822
Email: [EMAIL PROTECTED]
http://www.learningpatterns.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
