Right, i know it has a sitemap aspect... just based on what chas has
asked about RBAC before, I can only presume he's still looking for
more granularity than sitemap offers :-)
Perhaps it might work for Glenn though...
Cheers, Tim
On Sep 6, 3:44 pm, "marius d." <marius.dan...@gmail.com> wrote:
> Glen,
>
> Tim is correct however HTTP auth support + it's Role model can be used
> for SiteMenu as well. Please see:
>
> case class HttpAuthProtected(role: () => Box[Role]) extends LocParam
>
> You easily can specify that a Loc is a protected resource you just
> need to return the Role that guards this resource. This Loc will be
> served only if HTTP authentication succeeds and the Role match.
>
> So this is an RBAC.
>
> Br's,
> Marius
>
> On Sep 5, 7:57 pm, Timothy Perrett <timo...@getintheloop.eu> wrote:
>
>
>
> > Glenn, its simply not designed to do what your asking - however, the
> > most "lift way" of doing access control is with SiteMap, so
> > potentially look into that as a solution. You don't detail your needs,
> > but we've had this conversation several times on-list so just look
> > through the archives and that might spawn some other ideas for you.
>
> > Tim
>
> > PS: Is there any good reason you always put an ellipsis after your
> > name? For some reason it bothers me quite a bit!
>
> > On Sep 5, 5:32 pm, glenn <gl...@exmbly.com> wrote:
>
> > > Marius,
>
> > > I appreciate your reply, but the question I asked regards useage of
> > > the Role trait in what Charles
> > > refers to as a Role-Based Access Control (RBAC) system. I could not
> > > find this addressed in the
> > > Lift Book and, no, there is no illuminating code in the lift-
> > > authentication example. It's established
> > > the trait is not a good mixin for a mapper class in maintaining
> > > persistent role/access
> > > data. I was asking, on a lark, if anyone had ideas on a pattern that
> > > might help. I guess
> > > I've gotten an answer - No.
>
> > > I certainly don't expect Lift, out-of-the-box, to provide a complete
> > > authorization package
> > > and I would have been surprised if it had.
>
> > > Glenn...
>
> > > On Sep 5, 12:38 am, "marius d." <marius.dan...@gmail.com> wrote:
>
> > > > I'll let Tim provide you a concrete code example but AFAIK there is a
> > > > lift-authetication example in examples?
>
> > > > A few points:
>
> > > > 1. We support both BASIC and DIGEST HTTP authentication
> > > > 2. First, to apply authentication you need to specify which resource
> > > > (by URI) is a protected resource. Here we say that resource X is
> > > > protected by Role A (Roles are hierarchicaly structured)
> > > > 3. Secondly you set up the authentication function in Boot (for Basic
> > > > or Digest) you check the credentials. If authentication succeeds that
> > > > request is being processed.
>
> > > > Here is an example from lift-authentication:
>
> > > > LiftRules.httpAuthProtectedResource.prepend {
> > > > case (ParsePath("secure-basic" :: Nil, _, _, _)) =>
> > > > Full(AuthRole("admin"))
> > > > }
> > > > // This resource is protected by an AuthRole named admin.
>
> > > > LiftRules.authentication = HttpBasicAuthentication("lift") {
> > > > case ("someuser", "1234", req) => {
> > > > Log.info("You are now authenticated !")
> > > > userRoles(AuthRole("admin"))
> > > > true
> > > > }
> > > > }
>
> > > > When we try to access /secure-basic resource HTTP basic auth. is
> > > > applied. If
> > > > credentials are correct we set the AuthRole as admin on the
> > > > Requestvar
> > > > userRoles. If we would have set another role such as userRoles
> > > > (AuthRole
> > > > ("guest")) the resource would still not be served as guest has nothing
> > > > to do with
> > > > an admin. The lift-book describes the rules of Roles application.
>
> > > > All this has nothing to do with Mapper or Record etc. it is purely
> > > > about HTTP authentication and a simple authorization mechanism
>
> > > > Br's,
> > > > Marius
>
> > > > On Sep 5, 12:53 am, glenn <gl...@exmbly.com> wrote:
>
> > > > > I'm looking for direction on the best pattern for implementing basic
> > > > > authentication and authorization in Lift.
> > > > > For example, if I already have a Role mapper to store roles in the
> > > > > database, to what do I attach the Role trait in
> > > > > the net.liftweb.http.auth package?
>
> > > > > 1) The mapper. You would have to make sure there were no naming
> > > > > conflicts ( i.e., def name in the trait and the mapped string, name,
> > > > > in the mapper. Not the best design pattern to link the two, in my
> > > > > humble opinion.)
>
> > > > > or
>
> > > > > 2) A new class, or perhaps an object, with the trait that wraps a Role
> > > > > mapper instance.
>
> > > > > The other piece to the puzzle is managing the list of AuthRoles,
> > > > > create protected resources and build the Lift.authentication cases. If
> > > > > you limit this to Boot, then you give up on dynamic authentication and
> > > > > authorization, or do you?
>
> > > > > Glenn...
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
