I definitely agree for httpAuthProctectedResource to take a Req instead of a ParsePath even this is a breaking change but I doubt that many people are using this yet. I could implement this tomorrow if this is fine with everyone.
Br's, Marius On Jan 8, 10:28 pm, David Pollak <[email protected]> wrote: > On Fri, Jan 8, 2010 at 12:21 PM, Ethan Jewett <[email protected]> wrote: > > David, > > > For my use case (where pretty much the entire API is authenticated > > anyway), I would be perfectly fine if there was a second signature > > that tested a Req before the dispatch, allowing me to do my > > authorization code at that point. (And if the full State was available > > at this point, that'd be great, but I realize the difficulties with > > that.) > > > I can think of use cases where a resource should be readable > > (GetRequest) without authentication but writable (Post/PutRequest) > > only with authentication & authorization. The API for a public wiki, > > for example. These use-cases will require httpAuthProtectedResource to > > take a Req instead of a ParsePath. > > > Currently my implementation is to just dispense with the whole thing > > and deal with authorization in the stateful dispatch table by putting > > the authorization check matches before the application code matches. > > However, the only thing stopping a line-switch from ruining my > > authorization scheme right now is my unit tests, and I'd prefer if > > there were a solution that guaranteed evaluation of the authorization > > checks before the application code. > > Having auth guaranteed before the app code is hit is the right answer. > > Let's wait for Marius to give his thoughts as he was instrumental in the > Auth code (and will probably own whatever implementation we settle on). > > > > > > > Thanks for taking the time to look at this! > > Ethan > > > On Fri, Jan 8, 2010 at 1:28 PM, David Pollak > > <[email protected]> wrote: > > > 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: > > > > Change up the signature of httpAuthProctectedResource to have a Req > > instead > > > of the ParsePath > > > 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 frameworkhttp://liftweb.net > > > Beginning Scalahttp://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]<liftweb%[email protected]> > > . > > > 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 [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 frameworkhttp://liftweb.net > Beginning Scalahttp://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.
