David, Thanks for considering me - right now, the breakage is so small and only affects one, small app in production that is soon going to be swallowed by something else i've just written so its a non-issue for me right now.
Go for it :-) Cheers, Tim On Jan 8, 8:58 pm, David Pollak <feeder.of.the.be...@gmail.com> wrote: > On Fri, Jan 8, 2010 at 12:55 PM, Marius <marius.dan...@gmail.com> 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? > > > > > > > > > Br's, > > Marius > > > On Jan 8, 10:28 pm, David Pollak <feeder.of.the.be...@gmail.com> > > wrote: > > > On Fri, Jan 8, 2010 at 12:21 PM, Ethan Jewett <esjew...@gmail.com> > > 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 > > > > <feeder.of.the.be...@gmail.com> 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 <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<liftweb%2bunsubscr...@googlegroups.com > > > > >> > > > <liftweb%2bunsubscr...@googlegroups.com<liftweb%252bunsubscr...@googlegroup > > s.com> > > > > > . > > > > >> 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 lift...@googlegroups.com. > > > > > To unsubscribe from this group, send email to > > > > > liftweb+unsubscr...@googlegroups.com<liftweb%2bunsubscr...@googlegroups.com > > > > > > > > <liftweb%2bunsubscr...@googlegroups.com<liftweb%252bunsubscr...@googlegroup > > s.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<liftweb%2bunsubscr...@googlegroups.com > > > > > > > <liftweb%2bunsubscr...@googlegroups.com<liftweb%252bunsubscr...@googlegroup > > s.com> > > > > > . > > > > 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 lift...@googlegroups.com. > > To unsubscribe from this group, send email to > > liftweb+unsubscr...@googlegroups.com<liftweb%2bunsubscr...@googlegroups.com > > > > > . > > 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 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.