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. 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. thanks, Jon --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
