Hey Derek,
Thats great feedback! Cheers!
The main reason I hadnt manage to get away from case class or such
because i had:
val header = Can !! request.request.getHeader("Authorization")
in the base trait. This is such common functionality I dont really
want to repeat stuff like that, so thats why i was looking at some way
of making it work without a) repeating that stuff, and b) using
objects rather than class / case class.
I'll noodle this a bit more, but if you have any input that would be
awesome.
Cheers, Tim
On Nov 22, 5:58 am, "Derek Chen-Becker" <[EMAIL PROTECTED]> wrote:
> On second thought the PasswordLookup should really be an authentication
> function so that you can handle hashed passwords in the DB:
>
> trait HttpAuth {
> type Authenticate = (String,String) => Boolean
> ...
>
> }
>
> On Fri, Nov 21, 2008 at 4:33 PM, Derek Chen-Becker <[EMAIL PROTECTED]>wrote:
>
> > I'm getting a type mismatch, so I assume that's what you mean by
> > "dispatching code". It almost looks like you're mixing up object and class
> > apply semantics, since your call looks like
>
> > case r @ Req("badger" :: Nil, "", _) => new SimpleHttpBasicAuth(r){
> > PlainTextResponse("DFGDF")
> > }
>
> > The first problem is that the syntax you're using for SimpleHttpBasicAuth
> > is defining a new anonymous class, and it's not clear to me that that's what
> > you want. The second problem is that in your SimpleHttpBasicAuth class you
> > are asking for the request in the constructor *and* in the apply method
> > inherited from the HttpBasicAuthentication, so this syntax isn't going to
> > call apply, which *does* appear to be what you want. I'm not sure that
> > instantiating a new class for each request is the best approach. If you
> > don't mind me tossing in my two cents, here's how I might implement this:
>
> > trait HttpAuth {
> > type PasswordLookup = (String) => String
> > def apply(req : Req, realm : String, lookup : PasswordLookup)(success: =>
> > LiftResponse) : () => Can[LiftResponse]
> > }
>
> > object SimpleHttpAuth extends HttpAuth {
> > override apply(...)(...) = () => {
> > // check to see if auth was even sent
> > // compare realms
> > // extract user, compare sent password against lookup
> > }
> > }
>
> > object DigestHttpAuth extends HttpAuth {
> > ...
> > }
>
> > Just a rough idea, but from what I gather there's no need to use anything
> > other than static methods here since you really don't need to keep state
> > around (technically we need to remember recent nonces for Digest auth, but
> > that can easily be global). In any case, it looks interesting so far.
>
> > Derek
>
> > On Fri, Nov 21, 2008 at 7:22 AM, Tim Perrett <[EMAIL PROTECTED]> wrote:
>
> >> Guys,
>
> >> Im working on this http auth stuff - the code I have so far can be
> >> found here:
>
> >>http://github.com/timperrett/lift-http-auth-example/tree/master
>
> >> Right now i have a very strange error occurring with the dispatching
> >> code - i would appreciate it if someone can download it, take a look,
> >> and give some feedback on the direction im going with this.
>
> >> Cheers
>
> >> Tim
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
