> Technically this example does the same as > http://trac.sandbox.lt/auth/wiki/AuthFormMiddleware. Instead of > writing your plugin you would need to write isauthenticated function > that looks almost the same as identify function here.
Technically all auth mechanisms do the same. Quite frankly I doubt any "user" of the one or other auth framework cares about the intrinsics all that much. What matters is: 1) quick and potentially painless implementation 2) low cost of implementation because simply that's what pays the bills. Nobody pays for a "better" approach. These days you have to be able to do it quickly - no matter what. For me writing a "WSGI method" is pretty much the same effort as writing a plugin to repoze or auth - all those require me to write something to do the job. However if I can potentially reuse what I wrote in a year with some other framework is saves me time - and time is money these days. I think you posted the links to your WSGI only auth middleware (which isn't a middleware according to your own page) often enough. What is it you want to achieve with this crusade? More popularity? I guess all you'll get is annoyed core developers. Personally I don't care at all how the auth framework really works. I take what comes with the web framework of my choice, read up on the docs and then implement the application I intend to implement. Authentication is something as basic as a wheel to a car. I f the famework doesn't come with a auth that fits my needs, I just look for another framework that does. Also consider migration issues. I tried migrating a TG1x app to TG2. But when I tried a few weeks ago there was no "identity" the way it was with TG 1.x. So I'm sticking to 1.x until such time where someone (or maybe myself) writes a piece of "identity" code that allows decently easy migrating. I have 200000 lines of code, most depending on identity or some other thing in TG1.x. So unless I can migrate that code without rewriting it to pylons (which is the core of TG2.x) I'm just not going to migrate - period. If that means maintaining a possibly depreciated version of Turbogears, I must still say that's less work than migrating unless the reasons for migrating are really compelling. So just because you think the WSGI approach is superior to anyone else's approach, doesn't make it useable for many. Superiority was never an issue with software - if it was, Microsoft would have been bancrupt before it came out of the grarage.... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
