That makes alot of sense to me. Cascading strategies is fine if there is a class level guard as you suggest.
weepy On 7 Nov, 11:10, "Daniel N" <[EMAIL PROTECTED]> wrote: > On Fri, Nov 7, 2008 at 7:25 PM, weepy <[EMAIL PROTECTED]> wrote: > > > > 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! > > I see what you're getting at. There definitely is cases where multiple > strategies are equally valid to try. Take the case where you have Staff or > Customer as a user that can login. Each of these can be done via password > and login fields. Two strategies, one to deal with each class is certainly > the way I'd set that up, and each strategy is equally valid. I'm sure there > are plenty of other similar cases. > > We can be sure that this is not going into 1.0 behaviour, but having a class > level guard method is not a bad idea I think. By doing that we can test > that the strategy has some kind of chance of succeeding before we > instantiate it to let it run. This would keep the object count down which I > think would be a good thing. > > The strategies would sill be cascading. This to me is a valid method of > finding authentication, and I see examples of this in Unix permission models > which gives me confidence that it is indeed a valid methodology. > > I do like the idea of having some kind of conditional on the strategy so > we're being efficient though. > > What do you guys think > > Cheers > Daniel > > > > > 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 -~----------~----~----~----~------~----~------~--~---
