Ethan, This is a very interesting issue.
You're right the Req (uest) instance is not available at the time of the auth call. Normally, the Req object is available in S(tate), but S the S context is not entered at the time of the auth. So, I think we have two choices: 1. Change up the signature of httpAuthProctectedResource to have a Req instead of the ParsePath 2. Have a second signature that's tested with a Req The former is cleaner, but breaks people's code. The latter is uglier but gives the functionality that you're looking for. Anyone have any thoughts of breakage vs. lack-of-elegance? Thanks, David On Fri, Jan 8, 2010 at 9:45 AM, Ethan Jewett <[email protected]> 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]<liftweb%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to [email protected].
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
