Ideally, no one ever gets rejected or redirected.
Menus can be generated from a database so that only the pages
needed by a role are seen when you log into that role.
There should be a default or guest role for users that haven't logged in.
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]
>
> --
>
> 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]
