On Jan 8, 10: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?
We would have that but it looks a bit hacky to me.
>
>
>
>
>
> > 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...@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<liftweb%2bunsubscr...@googlegroups.com>
> > <liftweb%2bunsubscr...@googlegroups.com<liftweb%252bunsubscr...@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<liftweb%2bunsubscr...@googlegroups.com>
> > <liftweb%2bunsubscr...@googlegroups.com<liftweb%252bunsubscr...@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<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.
