> Weepy please explain. Well Jon kind of has a valid point about the cascading. As far as I understand, it makes sense if the cascade is thought of as essentially finding which strategy to try.
So if we turn the basic auth for example as : def valid? basic_authentication? end def run! #other stuff here. end Then we can try to find the first valid strategy by cascading through calling valid? on each strategy. When we've found one that's valid, then we call run! on it. If it works then all good. If it fails at that point then we either try to find another valid strategy (in reality there shouldn't really be two strategies that are both valid at the same time?) or just simply stop there. All I've really done there is make the guard explicit. Hope that makes (some) sense! On 7 Nov, 00:23, "Daniel N" <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
