> def run! > if basic_authentication?
Wouldn't it make sense to make these guards explicit in the API? I.e. each strategy should implement a method such as .valid? weepy On 6 Nov, 22:40, "Daniel N" <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
