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
-~----------~----~----~----~------~----~------~--~---
