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>
> .
> >> 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 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.
> >
> >
>
> --
> 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 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 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.
