Hi James, On Wed, Dec 10, 2008 at 7:05 PM, James Gardner <[EMAIL PROTECTED]> wrote: >> > a) the author or authkit is never around > > I am occasionally ;-) > >> > b) authkit is way over complicated > > Agreed, but authentication and authorisation *is* complicated and > there are lots of different use cases. > >> > c) autukit sucks in other ways >> > d) all of the above. > > ???
Sorry, I quoted someone else, and I didn't clarify to say that I don't agree with him 100%. Faux pas on my part there, I didn't intend to be insulting. What I tried to convey was that AuthKit doesn't fit *my* needs. > AuthKit can help with all these things apart from Customisable table > names but it doesn't provide a GUI admin system which seems to be what > you are after? Not at all. If I wanted automagic GUIs, I'd have chosen Django, with all it's terrible ideas ;-). What I wanted was a auth+auth layer that worked with my table names, and worked *with* me. When I looked at AuthKit when I was starting my project about 6 months ago, it *felt* it it was working *against* me. > That's not really true is it? Have you seen this: > http://authkit.org/svn/AuthKit/trunk/authkit/permissions.py > > There are permissions for all sorts of things to do with roles, > groups, IP addresses, time of day etc etc. The permissions system is > designed in such a way that you can create your own permissions too if > the defaults don't fit your needs. The problem I encountered with AuthKit when I looked at it, was that it seemed too manual. I didn't want manual, I wanted automagic. I didn't want to have to specify users or groups in my code, it needed to happen from information in the database. AuthKit has obviously progressed since then, and it looks like some of what I wanted has been developed, but when I looked at it, it didn't fullfil my needs. One of my other problems was that the documentation was rather confusing. It didn't show me what I presumed 90% of developers would want, that being to be able to use data from a database to drive the permissions system. The documentation when I last looked at it was heavily in favour of the more manual way of doing things, with hard-coded users and and groups, and very little (in fact, I didn't see any) of the documentation discussed using SQLAlchemy models for users, groups (or roles) and permissions. In fact, getting AuthKit to interface with SQLAlchemy might help to remove the hard-coded table names (which was a show-stopper for me). Perhaps one of the things you can look at some time is sprucing up the documentation to show how to use SQLAlchemy models to pull users, groups and permissions with AuthKit. I'm sure a lot of folks would appreciate it, and more folks would be encouraged to use AuthKit rather than write their own homegrown system. I hope this clears things up. I was in no way wanting to put down your effort into AuthKit. As an open source developer myself, I know how often it can be a thankless task when your code is still in it's early phases and people are demanding something you can't deliver. -- Raoul Snyman B.Tech Information Technology (Software Engineering) E-Mail: [EMAIL PROTECTED] Web: http://www.saturnlaboratories.co.za/ Blog: http://blog.saturnlaboratories.co.za/ Mobile: 082 550 3754 Registered Linux User #333298 (http://counter.li.org) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
