Ok, the changes are on review board. Br's, Marius
On Jan 8, 11:36 pm, Marius <[email protected]> wrote: > On Jan 8, 10:58 pm, David Pollak <[email protected]> > wrote: > > > On Fri, Jan 8, 2010 at 12:55 PM, Marius <[email protected]> wrote: > > > 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. > > > We've got code-slush on Sunday so we can do testing before Wednesday's > > 2.0-M1 release so as long as it gets in before Sunday, I'm cool. > > > Tim -- Is this going to mess with any of your existing code? > > > Hmmm... how about adding a ParsePath.unapply(req: Req) that would make sure > > we had source compatibility? > > We would have that but it looks a bit hacky to me. > > > > > > 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]> > > > <liftweb%[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]> > > > <liftweb%[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]> > > > <liftweb%[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. > > > -- > > 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.
