Problems with AuthKit (was: Django or Pylons - comparison details)

[Raoul Snyman]

> that is because
> a) the author or authkit is never around
> b) authkit is way over complicated
> c) autukit sucks in other ways
> d) all of the above.

This is unfortunately very true. I looked at AuthKit for possible
inclusion in a project of mine, but it's complicated in areas it
doesn't need to be, very basic in other areas, and not very flexible.
In the end I wrote my own authorisation and authentication system.

These are the things I wanted in my auth+auth system:
- Customisable table names
- Users, Roles and Permissions
- Hide/show menu items pulled from the DB, based on permissions
- Enable/disable links, based on permissions
- Hide/show sections of pages, based on permissions
- User access to pages/methods, based on permissions
- Fairly simple access checking

I haven't gotten the "access to pages/methods" going yet (not 100%
sure how to implement it yet), but I have the rest of the stuff
working.

Some of the reasons why I couldn't use AuthKit:
- Users/Groups far too limited (no "permissions")
- No way to show/hide page elements based on permissions
- No way to show/hide menu items pulled from the DB based on permissions
- Too rigid

I'd be quite happy to contribute my code to anyone who wants to start
an auth+auth project and would like to use my code (I don't have the
time to undertake yet *another* project).

--
Raoul Snyman
B.Tech Information Technology (Software Engineering)
E-Mail: raoul....@gmail.com
Web: http://www.saturnlaboratories.co.za/
Blog: http://blog.saturnlaboratories.co.za/
Mobile: 082 550 3754
Registered Linux User #333298 (http://counter.li.org)

[Dalius Dobravolskas]

Hello, Raoul,

> These are the things I wanted in my auth+auth system:
> - Customisable table names
> - Users, Roles and Permissions
> - Hide/show menu items pulled from the DB, based on permissions
> - Enable/disable links, based on permissions
> - Hide/show sections of pages, based on permissions
> - User access to pages/methods, based on permissions
> - Fairly simple access checking

So basically what are you dissatisfied about is not auth+auth system
but only its second part - authorization. Most probably authentication
part even works for you. I personally think that it is not possible to
write universal authorization system that will satisfy everyone but it
is possible to simplify writing one to very low level. Because of that
I try to push idea of some helper authorization functions:
http://trac.sandbox.lt/auth/wiki/AuthorizeMiddleware

Let's analyze your case in light of those helper functions:
> - Customisable table names
That's not important anymore. Just use you model.

> - Users, Roles and Permissions

Define your own and enjoy.

> - Hide/show menu items pulled from the DB, based on permissions

With AuthorizeMiddleware you should define HasPermission this way:

class HasPermission:

def __init__(self, permission):
self.permission = permission

def __call__(self, environ):
return model.User.query.filter_by(username=environ['REMOTE_USER']).join('permissions').filter_by(name=self.permission).count()
== 1

And use it this way:

class SomeController(BaseController):

@authorize(HasPermission('editor'))
def index(self):
return render('/editor.mako')

def edit(self):
if authorized(HasPermission('editor')):

I hope you understand now what I'm offering.

Even better. Let's return to AuthKit. As I have said you are
dissatisfied with AuthKit's authorization system. Authentication
system still works and you can use it with my helper functions. You
might find my authentication middlewares more suitable than AuthKit as
well: http://trac.sandbox.lt/auth/wiki/AuthFormMiddleware,
http://trac.sandbox.lt/auth/wiki/AuthOpenIdMiddleware . At least I
will be able to support that ;-)

> Some of the reasons why I couldn't use AuthKit:
> - Users/Groups far too limited (no "permissions")
> - No way to show/hide page elements based on permissions
> - No way to show/hide menu items pulled from the DB based on permissions
> - Too rigid

I will repeat myself. You can't use AuthKit's authorization
implementation. Just don't use it. Authentication part is reasonably
good in AuthKit (except OpenId).

--
Dalius
http://blog.sandbox.lt

[James Gardner]

Hi Raul,

Just to add to what Dalius has said...

> > 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.

???

> This is unfortunately very true. I looked at AuthKit for possible
> inclusion in a project of mine, but it's complicated in areas it
> doesn't need to be, very basic in other areas, and not very flexible.
> In the end I wrote my own authorisation and authentication system.

AuthKit tries to be a flexible basis for your own system. Sometimes it
is easier to create your own system than to base it on AuthKit, I
don't have a problem with that.

> These are the things I wanted in my auth+auth system:
> - Customisable table names
> - Users, Roles and Permissions
> - Hide/show menu items pulled from the DB, based on permissions
> - Enable/disable links, based on permissions
> - Hide/show sections of pages, based on permissions
> - User access to pages/methods, based on permissions
> - Fairly simple access checking

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?

> I haven't gotten the "access to pages/methods" going yet (not 100%
> sure how to implement it yet), but I have the rest of the stuff
> working.
>
> Some of the reasons why I couldn't use AuthKit:
> - Users/Groups far too limited (no "permissions")
> - No way to show/hide page elements based on permissions
> - No way to show/hide menu items pulled from the DB based on permissions
> - Too rigid

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.

% if authorized(RemoteUser()):
<a href="/signed_in">Click here</a>.
% else:
<a href="/not_signed_in">Click here</a>.

Good luck with your implementation anyway.

Cheers,

James

[Gustavo Narea]

Hello.

On Wednesday December 10, 2008 07:56:18 Dalius Dobravolskas wrote:
> I personally think that it is not possible to
> write universal authorization system that will satisfy everyone but it
> is possible to simplify writing one to very low level.

Agreed.

Let me advertise repoze.what a little bit... Sales are decreasing lately ;-)

> Let's analyze your case in light of those helper functions:
> > - Customisable table names

In repoze.what, you can customize table and column names, reuse tables from
different databases and hopefully customize anything you may ever want to
customize.

Or you may use no database at all and store your groups and permissions in
files (for example) using Ini files:
http://pypi.python.org/pypi/repoze.what.plugins.ini

> > - Users, Roles and Permissions

repoze.what supports them out-of-the-box. And in v1.0 final version they will
be optional, for those who prefer a different authorization pattern.

> > - Hide/show menu items pulled from the DB, based on permissions

repoze.what ships with so-called "predicates", including one called
"has_permission".

For example, TurboGears 2 developers use that predicate as:
> class SomeController(BaseController):
>
> @require(has_permission('editor'))
> def index(self):
> flash('You are an editor!')
> # ...

(@require is a rather small & trivial decorator provided by TG, which can be
used in other WSGI frameworks if you copy/paste it)

For more info: http://static.repoze.org/whatdocs/

Cheers.
--
Gustavo Narea <http://gustavonarea.net/>.

Get rid of unethical constraints! Get freedomware:
http://www.getgnulinux.org/

[Raoul Snyman]

Hi James,

On Wed, Dec 10, 2008 at 7:05 PM, James Gardner <ja...@pythonweb.org> 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.

[Mike Orr]

On Mon, Dec 8, 2008 at 6:40 AM, Raoul Snyman <raoul....@gmail.com> wrote:
> These are the things I wanted in my auth+auth system:
> - Customisable table names
> - Users, Roles and Permissions
> - Hide/show menu items pulled from the DB, based on permissions
> - Enable/disable links, based on permissions
> - Hide/show sections of pages, based on permissions
> - User access to pages/methods, based on permissions
> - Fairly simple access checking
>
> I haven't gotten the "access to pages/methods" going yet (not 100%
> sure how to implement it yet), but I have the rest of the stuff
> working.
>
> Some of the reasons why I couldn't use AuthKit:
> - Users/Groups far too limited (no "permissions")
> - No way to show/hide page elements based on permissions
> - No way to show/hide menu items pulled from the DB based on permissions
> - Too rigid
>
> I'd be quite happy to contribute my code to anyone who wants to start
> an auth+auth project and would like to use my code (I don't have the
> time to undertake yet *another* project).

There's a page in the Pylons Cookbook with HOWTO links for all the
generally-useful auth systems

http://wiki.pylonshq.com/display/pylonscookbook/Authentication+and+Authorization

... and a page for listing anything you think an auth system should
have that isn't currently covered.

http://wiki.pylonshq.com/display/pylonscookbook/A+Spec+for+Pylons+Auth+Packages

Please add any missing information here, for the benefit of all Pylons
users. The second page would be a good place to link Raoul's
unfinished code in case somebody wants to pick it up.

--
Mike Orr <slugg...@gmail.com>

[James Gardner]

Hi Raoul,

> 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.

Sorry, I hadn't seen the earlier thread, my fault too.

> 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.

I hear that a lot and am quite keen to get to the bottom of the
problem.

> 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.

That's interesting. What information exactly did you expect AuthKit to
be able to extract? At one level there is a Users API interface which
you can abstract for whatever back end you like but that clearly
wasn't what you wanted either. What sort of data did you want AuthKit
to be able to work on? I'm keen to take AuthKit where it needs to be
now I've mostly finished the book.

> 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.

Yes the docs were pretty poor. The only option was to really look at
the examples. I've now written two complete chapters about using
AuthKit in Pylons and they target only the core use case. It is
probably too late for you now but the two chapters are here:

http://pylonsbook.com/alpha1/authentication_and_authorization
http://pylonsbook.com/alpha1/simplesite_part_3

There are updated versions on their way as soon as Apress send me the
final texts but the current versions represent the best guide to
AuthKit and Pylons.

> 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.

That's precisely what the two chapters just mentioned do.

> 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.

I appreciate that, thanks. In all honesty I know AuthKit has caused a
lot of people quite a lot of pain though and I'm keen to sort it out.
I'm most of the way through closing all the open tickets now and if I
can get some clear guidance about the sorts of problems people have
run into I'm keen to help.

Cheers,

James