Hi Jon,
Replies are inline:
On Fri, Nov 7, 2008 at 2:27 AM, Jon Hancock <[EMAIL PROTECTED]> wrote:
>
> I was saving my critic on this as I have only one auth strategy at the
> moment. I've commented out the basic_auth one, which btw, I think
> should be commented out by default).
> The reason I'm saying something now is because the merb team wants to
> brand this thing as 1.0 and I should get my 2 cents in in case this
> input would have has some effect.
>
> It is my gut feel that trying one auth strategy and if it fails,
> trying the next is not what most app devs will want. Take for example
> the basic_auth strategy. If a request comes in that is a basic auth
> request, don't I know this from the point it hits the router? If so,
> why on earth would I want to first hit my DB using the form_auth
> strategy? And I realize in some cases, an app may be structured
> whereby the form based auth takes an id that may be either an internal
> app created id or an open_id id, I would imagine my app would also
> know at the point of submit or at least in some part of routing that
> the id is not of the format one of my app ids. In this case, I'd go
> straight to the open_id auh and again not do a guaranteed not found
> lookup on my DB.
>
Please actually take a look at the default strategies. They have guards on
the run method to determine if the given strategy has it's requirements
met. For example the basic auth one:
def run!
if basic_authentication?
.....
You can see here that the run method only comes into affect if the request
uses basic_authentication. Similarly in the form based logins:
def run!
if request.params[login_param] && request.params[password_param]
Again you can see that it is guarded and only goes into the logic of the
strategy if the parameters required for this strategy are present.
The point of having cascading strategies is that you can have descreet logic
for each login type and not muddy that logic with logic for other login
types. Just because you get a request into the router, your app doesn't
"know" that it's a basic auth request. You have to setup your app to ask
that question and respond appropriately. Then you have to also setup
whatever other login types you have, to ask the question and respond
appropriately. That's what strategies do. Rather than you having to write
some big if or case statment to decide which login type to persue, you write
a strategy.
Strategies have no business asking questions about other strategies logic.
It's inappropraite for example to have the form strategy ask if the request
is a basic_auth one for example. It should just say:
Does the request look like something that fits my strategy (i.e. does it
have the required params)
if yes... go nutz
if no.... return nil / false
Thats what a good strategy should do.
>
> My point is, my instinct tells me that chained/rolling auth strategies
> is the rare case. That the most efficient and most wanted case is at
> some point early in the request we know what type of auth to perform
> based on request or param info and we try that one and only that one.
> Or at least try the most obvious strategy first.
How do you assess which strategy is the most obvious? It's easy when you
know what the request is. But how do you do it when you have no idea what
the request will be? Do you then extract the logic from each strategy to
outside the strategy to determine which strategy should be run first?
>
>
> thanks, Jon
>
Jon, If you really don't like cascading strategies, just comment the
merb-auth lines in your dependency.rb file. You don't have to use it if you
see that it is inefficient. We don't want to force anyone into a solution
that they find sub-optimal. I'm also up for improvements to the auth
framework for sure.
Cheers
Daniel
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"merb" 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/merb?hl=en
-~----------~----~----~----~------~----~------~--~---
