On Fri, Nov 7, 2008 at 11:11 AM, weepy <[EMAIL PROTECTED]> wrote: > > > 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 >
Weepy please explain. I think I'm getting a picutre in my head but I'd like to hear yours and Jons thoughts on it. Cheers > > > 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 -~----------~----~----~----~------~----~------~--~---
