Tim,
You are right. Protecting resources and menu items is well documented
in Lift. But providing read/write permissions, and even restricting
access to
specific data entities based on a subject's role, if that's what you
mean by
more granularity, is often a required use case in an application.
Dividing up read-only views and editable templates into different
resources helps. And limiting data access is certainly doable. It
would just
be nice to centralize some of these features, and that's what I'm
trying achieve in my
code.
Glenn . - oops, I almost lost myself there.
On Sep 7, 12:53 pm, glenn <gl...@exmbly.com> wrote:
> Marius,
>
> In practical terms, if I am already using an If LocParam, as in the
> following:
>
> If(() => User.isa_?("admin"), S.?("not_authorized"))
>
> what does adding
>
> HttpAuthProtected(() => User.authorize("admin")) to the Loc do?
>
> Here, I've had to define User.authorize to make things work, as:
>
> def authorize(roleName:String): Box[Role] = {
> val credentials : (String,String) = User.currentUser match {
> case Full(u) => (u.email.is, u.password.is)
> case Empty => (null, null)
> }
>
> User.isa_?(roleName) match {
> case true => {
> LiftRules.httpAuthProtectedResource.append {
> case (ParsePath("listContents" :: _, _, _, _)) => Full
> (AuthRole("admin"))
> }
> LiftRules.authentication = HttpBasicAuthentication("lift")
> {
> case (credentials._1, credentials._2, req) =>
> AuthRole(roleName)
> true
> }
> Full(new _root_.net.liftweb.http.auth.Role{
> def name = roleName})
> }
> case false => Empty
> }
>
> Rather verbose, don't you think.
>
> elipsisless Glenn
>
> On Sep 6, 8:27 am, Timothy Perrett <timo...@getintheloop.eu> wrote:
>
> > 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
-~----------~----~----~----~------~----~------~--~---
