Tim,
Right now I'm trying to authenticate an API call using a session token
that can be resolved to a specific user. Authorization is then based
on the user.
My thought was that I might be able to bypass issue #2 by creating a
custom class extending the HttpAuthentication trait (first with Lift
sessions, then with OAuth later), but if role authorization doesn't
distinguish between request types (issue #1), then it's not terribly
worthwhile since I'm going to have to do all my authorization in my
application code anyway.
More in my response to David...
Ethan
On Fri, Jan 8, 2010 at 12:56 PM, Timothy Perrett
<timo...@getintheloop.eu> wrote:
> 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.
>
>
>
>
--
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.
