Daniel, I don't have a fully formed example to prove it should not be the way it is. I just brought it up as my instinct tells me that the controlling action and condition to execute the strategy should be in something outside the strategy itself and therefore, by default, they are not chained. Since I'm only using one strategy at the moment, it has no effect on me right now. I just brought it up as I think it may be an issue.
I do think that for a 1.0 release, the merb-gen behavior should have the basic_auth strategy in merb/merb-auth/strategies.rb commented out by default. thanks, Jon On Nov 7, 8:23 am, "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 -~----------~----~----~----~------~----~------~--~---
