Ethan,

Dont worry, this appears to be a confusing thing for many lift new-
commers. The role stuff is *only* for use with HTTP authentication...
for the scenario you described, it wont help you.

What is it you want to authenticate? A user? An api call?

Cheers, Tim

On Jan 8, 5:45 pm, Ethan Jewett <esjew...@gmail.com> wrote:
> Hi all,
>
> Let me preface this by saying that I'm learning Lift, so I'm a
> relative newbie. Please be gentle.
>
> I'm struggling to figure out a good way to do role-based authorization
> natively in Lift. Based on examples in the Lift book, the wiki, and
> reading the Lift source, I've gotten to
>
> val roles = AuthRole("super-admin",
>   AuthRole("admin",
>     AuthRole("user")
>   ),
>     AuthRole("integration-admin")
> )
>
> LiftRules.httpAuthProtectedResource.prepend {
>   case ParsePath("api2" :: "users" :: _, _, _, _) =>
> roles.getRoleByName("integration-admin")
>
> }
>
> This is with the intention of introducing Lift-based roles into the
> ESME code base, starting with the API. (ESME is an enterprise
> micro-messaging system:http://cwiki.apache.org/confluence/display/ESME/Index)
>
> There are two issues with this approach:
>
> 1. Because LiftRules.httpAuthProtectedResource takes ParsePath() as
> its match instead of Req(), I can't require a different role for a
> GetRequest vs. a PostRequest, for example. This is a requirement for a
> pure resource-oriented (RESTful) approach, since we'll often want to
> authorize users to read on a resource (GetRequest), but not
> write/change it (Post/Put/DeleteRequest).
>
> 2. It appears to require use of HTTP basic or digest authentication in
> order to assign a role to a user (using userRoles). We don't currently
> want to use either. (For our API we're currently using a token-based
> login with headers for persisting the session.)
>
> I feel like I'm missing something in the area of #2 because the Lift
> book uses "LiftRules.protectedResource", which doesn't seem as
> authentication-bound on the surface, but this function is no longer in
> Lift. Also, I've seen references on the mailing list to "form-based"
> authentication, so I'm thinking that there is another way.
>
> Are there ways to handle both 1 & 2 in Lift, or is this something that
> people generally handle in their application logic?
>
> Thanks,
> Ethan
-- 
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@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.


Reply via email to