Designing user logins - part two: permissions

The complexity of a permissions system depends on the complexity of the site it needs to serve. For the code being developed here, the intention is that:
a) everything can be managed via the web interface and
b) the resultant site is fully modular and general-purpose.

This design philosophy is technically known as "Making life difficult for yourself", although the theory is that careful and advanced design early on will pay back massive dividends later on. Certainly, my experience on Infinite Penguins shows that retro-fitting permissions and management is *really* tricky - so this time, I want to get it right from the start.

The next layer of complexity lies in defining what permissions you want to manage. This page of notes on Infinite Penguins: gives some idea of how many different permissions can be managed on a modular site. Furthermore the sparse population of the table shows that trying to generalise permissions can be of dubious effectiveness.

Additionally the form of permissions used in that code uses six database tables in a chain - something of a naive, if not foolish, design that assumed that "the database engine will absorb the complexity". It doesn't. O(n6) complexity makes database engines explode messily and cripples websites. Hopefully you'll allow me to spare my embarrassment and not give you the details of that, and instead state categorically that I'll not be doing it again.

So, I need a simpler, and probably less overwhelmingly generic solution - but still use some constants of design. Permissions will be divided into two classes: permissions relevant to a whole module (meta-permissions, in the linked article above), which will be attached to the core 'modules' table, and permissions relevant to an instance within a module (eg a single journal, a single gallery, etc), which will be attached to that row of the relevant table in the module.

Permissions will not be allocated to single users, but to groups of users (the Infinite Penguins code allowed groups of groups, which was another cause for the over-complexity). These groups can then be marked as "managed by (specified) group", "managed by (specified) user", or "managed by site admin" - this last, we'll set up as a special flag in the user table.

Some options in the site (eg, do user accounts need pre- or post- approval?) will have to be set globally in a "site options" table. These are simply key-value pairs that can only be changed by a site admin, who will be an "ultimately trusted" user.

Finally, site admin powers - omnipotence in the site - will not be configurable via the web interface. These will have to be set manually in the database, for maximum security.

This is something of a rapid overview, and most likely leaves questions to be answered. Comments welcome, and I'll fill the gaps in later posts.
Posted by parsingphase, 2004-04-11 14:46

Anonymous user



Contact Richard