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