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(() =
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
On Sep 8, 7:00 pm, glenn gl...@exmbly.com wrote:
Marius,
I guess there is little more to be said on this issue. Keep in mind
that
in many real-world applications, dynamically assigned user roles are a
requirement. And it's possible for users to have multiple roles, each
in a different
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
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.
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
Marius,
Please bear with me. I'm a little slow in following the logic here.
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,
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
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:
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
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
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
Glenn,
If Marius doesn't beat ne to it, I'll reply tomorrow morning. The
system we implemented for auth was not meant to be composed with
matter per-say, not in the way you think however...
Presumably you've looked at the http Auth example in the github repo?
I'm not sure why on earth you
Tim,
I tend to agree with you that the Role trait is not a good mixin for a
role mapper, which is why
I raise the question.
Maybe I'm looking in the wrong place, but the http-authentication
example in liftweb.sites on github
doesn't have much code. The LiftBook is a more complete example. And
There is a big difference between authentication (making sure someone
is who they claim to be) and authorization (making sure that now that
we know who they are, they have permission to do what they're trying to do).
It seems to me that what you're referring to is a Role-Based Access
Control
15 matches
Mail list logo
