On Sep 8, 6:12 pm, glenn <gl...@exmbly.com> wrote:
> Marius,
>
> With your help, I think I'm getting closer to understanding what is
> needed
> here.
>
> One thing though, is that I believe I do need to manually check if the
> user has the
> appropriate role (in the DB) before I can set userRoles RequestVar.
> See, in my application,
> I have no way of knowing in advance if a logged-in user is authorized
> to access
> a particular resource. I'm trying to accomplish that programatically.
Well if when authenticating a user (LiftRules.authentication) you
can't determine the Role, then this mechanism probably won't help you
and you need to build your own.
> And, don't forget, roles
> can be changed at any time in the application.
I assume that a "super-admin" user would be able to change roles for
other users right? ... If so you just need to update data in your DB
for say user X. So when User X authenticates you'll get the new role
assigned. But maybe this is not how your app is designed to work.
> In other words, I
> can't just assume it in my
> authentication function and make the assignment there.
>
> Does that make sense? This is not to say that I can't work
> tangentially to Http basic authentication
> in Lift and create my own, just that I'm trying to incorporate the
> work already done so I don't have to.
Lift's HTTP authentication and authorization is built on very simple
principles such as:
1. In the authentication function you typically know the role for that
user.
2. Resources (URI's essentially) are protected by hierarchically
structured roles that are matched with the role determined by the
authentication function.
>
> Glenn
>
> On Sep 7, 11:24 pm, "marius d." <marius.dan...@gmail.com> wrote:
>
> > On Sep 8, 1:18 am, glenn <gl...@exmbly.com> wrote:
>
> > > Marius,
>
> > > Please bear with me. I'm a little slow in following the logic here.
>
> > Don't worry glen.
>
> > > I understand I can protect the resource as you suggest from all
> > > but users with admin roles, using the LocParam,
>
> > > HttpAuthProtected(() => Full(AuthRole("admin"))))) .
>
> > > Now, when I click on the link, if no user is logged in, the system
> > > asks for a username and password to connect, but that's a user
> > > on the host. not an application user.
>
> > Not necessarily. It is any type of user. In your authentication
> > function you can go in DB and validate the receiving credentials as
> > application user.
>
> > > Somewhere, I need to assign the
> > > currently logged in user the AuthRole("admin") needed to access
> > > the resource.
>
> > Correct. And you dothis by setting userRoles RequestVar.
>
> > > Seems to me I need code like this to run someplace:
>
> > > def authorize(roleName:String): Box[Role] = {
> > > object userRoles extends RequestVar[Role](null)
>
> > > 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.authentication = HttpBasicAuthentication("lift")
> > > {
> > > case (credentials._1, credentials._2, req) =>
> > > println("John is authenticated!")
> > > userRoles(_root_.net.liftweb.http.auth.AuthRole
> > > (roleName))
> > > true
> > > }
> > > Full(new _root_.net.liftweb.http.auth.Role{
> > > def name = roleName})
> > > }
> > > case false => Empty
> > > }
> > > }
>
> > > Can't be in Boot,
>
> > No you do not. Lift takes care of the roles matching for you. You
> > don't need to manually test if a user is-an admin or some other role
> > in order to access that resource. Please keep in mind that is just for
> > accessing resources (URI-s) if you need to do more complex logic in
> > your code and see if the user is an admin or having some other Role
> > that you'd probably need to save the Role into a SessionVar or into
> > your User object.
>
> > All I want here is to explain how HTTP based authentication and roles
> > based authorization works. I am definitely not claiming that this is
> > enough for all applications as currently we don't have HTTP based
> > authentication with forms for example ... but I think we should add
> > that as well.
>
> > > Glenn
>
> > > On Sep 7, 1:36 pm, "marius d." <marius.dan...@gmail.com> wrote:
>
> > > > On Sep 7, 10: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?
>
> > > > It sais that this Loc is protected by the returned Role. Thus to
> > > > access this after passing the authentication the Role specified in the
> > > > authentication function (by setting userRoles) must be the same as or
> > > > a child of the Role the is protecting the Loc.
>
> > > > > 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"))
> > > > > }
>
> > > > Why do you need to use httpAuthProtectedResource if you' using
> > > > HttpAuthProtected LocParam ?
>
> > > > > 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.
>
> > > > Your code is verbose but I don't see the justification for this
> > > > verbosity:
>
> > > > LiftRules.authentication = HttpBasicAuthentication("lift") {
> > > > case (username, password, req) => {
> > > > // Do you authentication in DB or whatever and you
> > > > determined that this is an admin user
> > > > userRoles(AuthRole("admin")) // userRoles needs to be
> > > > set. It is a RquestVar.
> > > > true
> > > > }
>
> > > > In Boot you have:
>
> > > > Menu(Loc("listContents", List("listContents"), "listContents",
> > > > HttpAuthProtected(() => Full(AuthRole("admin")))))
>
> > > > When you use HttpAuthProtected LocParam Lift appends a function to
> > > > LiftRules.httpAuthProtectedResource so you don't need to do it
> > > > manually.
>
> > > > This authorixation scheme is only about protecting resource by roles
> > > > and you do this almost declaratively and for authentication I thing
> > > > the things are pretty straight forward. One a user is authenticated
> > > > (using HTTP authentication) you need to specify the Role for this user
> > > > and you do this using userRoles RequestVar.Thus /listContents can only
> > > > be accessed if:
>
> > > > 1. user passed authentications
> > > > 2. user's Role is an "admin" or a child of the Role specified in
> > > > HttpAuthProtected
>
> > > > > 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
>
> ...
>
> read more »
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
