implementing a permission system for a WACT project

Monday, January 31. 2005

implementing a permission system for a WACT project

I'm thinking about this for two weeks now and I cannot decide. I need a permission management system preferably with an existing web UI to control the rights. I may create one on my own; it can be a great benefit for the project, because this provides unlimited flexibility. The project itself is a very complex portal which will hopefully get hundreds of thousands of hits every single day - sooner or later that is. I shouldn't depend on other projects at all.

At the same time, I'm an open-source guy, so I'm also leaning towards using existing systems; I selected LiveUser and phpGACL for the purpose. The big question is, if I should:
a) use LiveUser, which means including PEAR on every request, which wouldn't happen if I didn't choose LiveUser. I prefer LiveUser because I already know it (well, the last version I used is 0.3.0-beta, they actually have 0.14.0-beta) and because I know many of its developers personally plus I tend to like them and trust their knowledge.
b) use phpGACL - it needs ADODB but I don't use ADODB at all and I don't plan to do so. It doesn't need PEAR though. You are right, I'm a PEAR developer but I don't use PEAR in this project at all. phpGACL is also very promising: "GACL class: Designed to be very small (517 lines of code including comments) and very fast, this class strictly takes care of the permission checks."

LiveUser has LiveUser_Admin and phpGACL has its own "Admin Interface" as well. The latter is currently more advanced as far as I know.

Oh, and if it counts, the project is based on WACT. I need to access the permission system both in the PageControllers and inside the templates, so I will have to create some new tags as well, which is an exciting task - hehe, code generation rulez :) I also know that Ian White has already started working on a LiveUser implementation for WACT.

Actually I think I will choose one of the systems above, run profiling tests at the end of the development and create a custom system if they aren't as fast as they should.

LiveUser vs phpGACL - PEAR vs ADODB.. what should I choose and why? Any tips are greatly appreciated :)

Posted by Norbert Mocsnik in php/web at 21:43 | Comments (31) | Trackbacks (0)

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

Well this might be objective review since I'm one of the LiveUser developers, but LiveUser supports more DBALs (some dude is going to make the ADODB containers afaik) and last review I saw (which Jeff posted on the WACT dev ML) then MDB2 did better then ADODB, so there's +1.

Note I have looked at phpGACL at all, but as far as I can tell and I've been told by others that have used LU is that LU is much more flexable (0.14.0 and up) like say in the Admin part, we generate queries there, nothing hard coded so you can join in much more tables if you need and do all kinds of fun stuff if there is any need for that, both when your inserting/modifying or fetching data.

Now also LOC (line of code) doesn't always matter, so that something is only 500 lines isn't very impressive :) Either suggests is has few features or is splitted up in a lot of files and I/O stuff is very expensive (That's where WACT is failing IMHO :P).

As you might also know, Greg has already fixed the issues that made including/extending PEAR such a burden.

LiveUser also has observers so it's rather easy to "inject" your own functions and make the execute when a person logs in or out or what ever :)
So that's kind of nice feature.

You have to note 0.14.0 is the first release after we completetly rewrote LiveUser and splitted the Admin part into it's own package, so there are bugs and there are unfinished things, just look at pear.limbourg.com for more info, but 0.15.0 is due very soon, also 0.2.0 of the Admin package.

Regarding the admin interface for phpGCAL is much more advanced, in what way then ? :)
I very much doubt it, specially since I wrote most of LiveUser_Admin my self :) (funny face)
Anyway look at example 1 in LiveUser_Admin, that's my test stuff as well as showing off all the functions, nicely packaged into some kinky example :)

Also as I've told you, a cache container will be added later on in LU, making things much nicer when people want performance, just someone has to step up to make it, else it will have to wait a bit.

Anyhoo, I'd say you shouldn't look for performance in auth/permission frameworks/scripts, because more checks == less speed, more checks == more security or well in most cases :)
Plus there isn't much heavy lifting stuff in the client (if any) so it should be rather fast, admin parts can most of the time be a little slower then the rest because they're much less used :)
Ohh yeah did I mention that you can log errors ? (well those that are raised by error stack, but you can add more logging features via observer stuff.)

I guess that phpGCAL is a bit more stable then LiveUser, because we're re-written LiveUser couple of times, and each it gets better, but current LU (CVS) is very stable indeed, even tho we just rewrote it :P

Anyway which ever way you go, good luck, but remember LiveUser is flexable! ;)

#1 Helgi on 2005-01-31 22:53 (Reply)

What LiverUser can learn from phpgacl is how to write good end user docs. Within 2 hours you know how it works. LiveUser is wasting time of end users! As far as i know a day ends after 24 hours.

#1.1 atu on 2005-02-01 11:41 (Reply)

What we've been doing is not writing docs on a moving target, it's just none sense to write docs on a thing that has been re-written few times, when it gets stable then we will think about writting docs, also IMHO the users should help us write them when they come familiar with the package, which hasn't happened until now, only thing we get is "WRITE DOCS" and no one ever writes down what we tell them when we answer their questions, kind of egg and a chicken situation for now here :-)

We tho have around 6-7 examples which are very good and people can easily learn the basics from that.

I just think people don't realize that LiveUser is still beta software and should expect the quality as such :)

#1.1.1 Helgi on 2005-02-01 12:09 (Reply)

My vote goes for phpgacl. May its not as flexible as you mentioned but i can focus on projects. Sorry, but i cant spend my time to get LiveUser out of beta. When its done i will rethink my view.

#1.1.1.1 atu on 2005-02-01 12:25 (Reply)

This is a valid point. It always depends on the project if you can allow such things.

#1.1.1.1.1 Norbert on 2005-02-02 07:29 (Reply)

End user docs are important but I can live without them. What I think is that you can use an open source tool efficiently only if you know its whole source, so that you can even modify it when needed. Whatever I choose to use in the project, I will review its full source first to know its internals. This is an essential requirement for me.

#1.1.2 Norbert on 2005-02-02 07:27 (Reply)

DISCLAIMER: I'm the main author of phpGACL, and I've never had the opportunity to use LiveUser.

phpGACL was designed for moderate (not insane) flexibility, and speed. In the 3 years since I first released phpGACL, I have only come across one scenario that it couldn't handle gracefully, and that had to do with IP address masking. Obviously the more flexibilty you have, the less speed you get as well, but I believe I have hit a pretty good middle ground on this issue. Once you enable caching in phpGACL though, speed is a non-issue as acl_check() calls are sub-millisecond, and the cache is only invalidated on specific case-by-case basis when the corresponding ACL is updated, which is key to a truely efficient cache mechanism.

Stability. phpGACL is stable, and has been for years, it has also never gone through a complete re-write because the need has never been there. The largest patch made to it was when we added MPTT support.
phpGACL was originally written to handle the permission requirements of one of the largest web hosting companies in the world. Even though I no longer work for the company (this was years ago), to this day it still churns out millions of hits a month with a very ACL intense web application. The "home" page of the application does over 500 acl_check() calls alone and thanks to its efficient caching mechanism, phpGACL is one of the lighest parts of the application.

LiveUser sounds like it has some pretty nifty features, but do you truely need them all? If your looking for a "out of the box" ACL implementation that you can use NOW, and that you KNOW will be fast, the choice seems pretty obvious. Who knows, maybe a few months down the road when LiveUser is stabalized and optimized for speed, the choice will be much more difficult.

Regardless though, you need to pick the best tool for the job, whichever that may be.

If you have any questions regarding phpGACL, feel free to email, or subscribe to the mailing list.

Good luck.

#1.2 Mike on 2005-02-02 00:24 (Reply)

Thanks for joining the conversation! One time I built LiveUser into a webapp and never used phpGACL until now. I'm impressed by the pros of phpGACL you can read in my other comments. What I don't like is the ADODB usage and that I can't see the difference between ARO/AXO/ACOs. LiveUser has users, groups etc, thats easier understand. I probably just need to spend more time on phpGACL to clarify this in my mind.

Based on the comments, I should choose between:
- functions & flexibility, less stability, less performance, PEAR
- stability & performance, less functions & (maybe) less flexibility, ADODB
This means now, actually, currently, because both projects are under constant development.

I'm gonna have a hard time :) Originally I had to choose between PEAR vs ADODB, now here are 4 more factors that I have to keep in mind. Thanks for opening up my eyes everyone.

Now I have to find out what functions are really needed.

#1.2.1 Norbert on 2005-02-02 08:07 (Reply)

echo str_replace("can't see the difference", "can't make difference", $comments['1.2.1']);

+ yet

#1.2.1.1 Norbert on 2005-02-02 08:21 (Reply)

I agree that users, rights, roles, groups, etc may seem easier to grasp at first, however I specifically decided against using those "names" with phpGACL because they weren't generic enough. For example, what if your application doesn't have the traditional form of "users"? What if "roles" don't really fit?

A quick glance in the docs should clarify the names, in my opinion they do make quite a bit of sense while still being truely generic.

ARO - Access Request Object (normally users)
ACO - Access Control Object (AROs request access from ACOs)
AXO - Access eXtension Object (extends ACLs in to the 3dimensional world)

Also, I specifically decided to use ADODB over PEAR because:
1. It was faster, and if you look at the C version of ADODB, it is even faster yet.
2. It was much more flexible. Meta tables, XML Schema, these features are huge when developing a application that other people need to install themselves. In my opinion, ADODB is truely database independant, whereas PEAR::DB is no where close yet.
3. It has been much more consistent over the years. From the outside looking in, it seems PEAR doesn't know which direction is up. PEAR::DB, MDB, and now where does PHP5 ADO fit in? No thanks, I prefer something that gets the job done, and has for years.

One other thing, does LiveUser support group hierarchies with inheritance? This is a feature that in my experience is invaluable, and is also where phpGACL shines. It makes administration of ACLs many orders of magnitude easier, and even faster in most cases. Having administered a large web application with over 60,000 objects in 200 groups, about 300 unique "rights" (ACOs), and several hundred ACLs, it can become a nightmare very quickly without this feature.

#1.2.1.2 Mike on 2005-02-02 08:34 (Reply)

I wasn't against ADODB for the benefit of PEAR, I was against db abstraction layers in general (although I prefer PEAR packages over ADODB).

I don't want to start an endless discussion on this, just want to help you by telling about the state of PEAR db packages, as I see it now. The DB package was the first abstraction layer in PEAR. This is why it's so popular and that most of the other packages are based on it. It's also part of the PEAR core distribution -> part of the PHP distribution as well. I think PEAR DB will be kept maintained and improved until other packages depend on it. MDB/MDB2 are newer and provide more functionality, I'd choose MDB if the other packages I use (e.g. DB_DataObject) wouldn't depend on DB. Regarding the PHP DAO, if you mean PDO, as far as I remember MDB3 will support that/based on that or so. Lukas is the lead developer of MDB, he also takes part in PDO development afaik.
PEAR is not a mess, despite the fact that some people think so.

LiveUser does support group hierarchies with inheritance, if you mean subgroups of subgroups of subgroups of groups. In 0.3.0 it was achieved by a table with group_id and subgroup_id fields. It supports right hierarchies as well (implied rights).

The numbers you mention in your comment and on the phpGACL website is very convincing.

Thanks for clarifying the ARO/ACO/AXO thingie.

#1.2.1.2.1 Norbert on 2005-02-02 09:17 (Reply)

Thats definitely good that LiveUser supports hierarchies, however if you know your application has a chance of requiring complex ACLs, I would make sure that its hierarchy is efficient.

A simple group_id, parent_id column combination is not efficient at all in SQL. phpGACL used to use this method for its groups about 1.5 years ago, but we moved to the Modified Preorder Tree Traversal (MPTT) format and gained orders of magnitude in performance when dealing with complex group hierarchies.

Something to consider if performance is truely an issue.

#1.2.1.2.1.1 Mike on 2005-02-02 16:42 (Reply)

Yeah we have such things as groups hierarchies with inheritance
Like norbert said, it's subgroups and also some stuff with the rights :)

MDB == PEAR::DB + Metabase ... MDB2 is just another major version of that and has that XML Schema you talked about, it even will be splitted of into it's own package so people won't have to download whole MDB2 just to use it.
And also MDB2 will have PDO driver last time I knew.
Plus it's the quickest as of yet in PEAR, last benchmarks I saw it performed better then ADODB in all tests but one IIRC, those tests were on the WACT mailinglist.

#1.2.1.2.2 Helgi on 2005-02-02 11:35 (Reply)

I've got almost the same problem. LiveUser looks very interesting but the performance is bad.
So I wrote my own method to check the user rights which get all user rights from LiveUser and write it as an array into the session. The result is that you have to include LiveUser (and PEAR etc) only once - when you check user rights the first time. Later you could check rights from the $_SESSION.

#1.2.1.3 Radek (Link) on 2005-02-02 14:11 (Reply)

Storing permissions in the session works, but it only works well if you have a very small number.

With a lot of applications that use phpGACL, this is simply not a choice. Quite a few people also use phpGACL to limit access to individual rows in their database. For instance, in a groupware application they have ACLs on every single "contact", or every single appointment in the calandar. Storing this amount of data in the session simply isn't an option.

Something that I know I have used on many occasions is the "real-time" ability of phpGACL (cache invalidation making this possible), where mid-session you can change ACLs for someone browsing the application. A good example of this is to bring down just a portion of the application to do maintenance on it. You can immediately "disable" a specific ACL and it takes effect immedately. Caching permissions in a session make this much more difficult to do.

#1.2.1.3.1 Mike on 2005-02-02 16:34 (Reply)

Hmm I agree. I've never thought that anyone could have few hundrends (even thousands) rights in his system! But even if he has if one user could have so many rights it looks for me like a bad design.
As you said in this situation it could be cached in the file. But of course it won't work with live changing rights (and you will probably want it with few thousands rights:).

I have to look at gacl, could be helpfull with really big amount of simple rights which has to work really fast :)

#1.2.1.3.1.1 Radek on 2005-02-02 17:26 (Reply)

Regarding DBALs, I'd be much happier to see native mysql/postgresql support without an abstraction layer. I generally consider DBALs useful but I don't like to introduce this layer in a huge project where performance counts.

"Joining more tables in" sound very promising.

LOC: you are right, it doesn't really matter, especially if I use a bytecode cache, if I'm right.

Yep, I know that Greg worked a lot on the PEAR core and he always does a great job. However this doesn't change the fact that currently there's no PEAR on the server and the permission system would be the only reason to install it. This undoubtedly may introduce further problems, not because of PEAR but because it's one more software/library/whatever installed on the server. Well, I could install it somewhere else and upload PEAR files manully; I know it well enough to do it.

Observers are cool, I'll look into the details of LiveUser now for sure.

Concerning the full rewrite, +1 because it probably has a great internal structure now, -1 because it probably will change many times in the near future.

I know that you wrote most of the LiveUser_Admin code, it's v0.1, this is why I thought it has less functions than the phpGACL admin.

Adding a cache controller is +1, "later" is -1 because in open source you cannot assign fixed deadlines while I do have them in the project :)

"more checks == less speed, more checks == more security". I don't necessarily agree on this. Why should you check multiple times if some user has some right or belongs to some group?

Right, it simply doesn't count if the admin is slow.

Logging errors is cool.

Thanks a lot for the extensive introduction!

#1.3 Norbert on 2005-02-02 07:24 (Reply)

Actually we're kinda satisfied with the current structure and we aren't going to change it until at first in LiveUser2, this structure will stay until then :)

LiveUser_Admin matches the old admin class in all functionality, and I even added 2 functions on top of that if remember correctly :P

I mean sanity checking, not if the user has rights and such, but checking if the data is valid we place is.

#1.3.1 Helgi on 2005-02-02 11:26 (Reply)

Having spent the better part of a week trying to get LiveUser to work within my application -- and reading every doc and tutorial I could find in Google, I had to come to the conclusion that LiveUser's API is still a moving target, which is reflected by it's non-existent documentation.

I found that the examples weren't applicable to real-world application, and pear.limbourg.com was down a bunch when I was trying to figure everything out.

I ended up going with Auth and phpGACL for authentication and rights management, and am very pleased with the decision. I was able to get both up, running and tested within a couple hours, and I'm fairly confident that I'm not going to have to yank my authentication code for a future upgrade of either library.

LiveUser holds a lot of promise, and I'll be excited to see it mature. If someone on the LiveUser team wanted to give me some good working examples and a crash course, I could probably be convinced to write and maintain the end-user documentation for the project.

#1.4 Jeromie Clark (Link) on 2005-03-31 00:38 (Reply)

I'm not objective either but LiveUser gives you flexibility and it doesn't extend PEAR (at least last time I checked) so don't worry too much about that.

#2 arnaud on 2005-02-01 10:32 (Reply)

What scares me in LiveUser's source [1] is
require_once 'PEAR/ErrorStack.php';
require_once 'PEAR.php';
+ 1638 lines of code (well, including extensive comments)
+ it includes additional files even to check a single right

At the same time, as Helgi mentioned, Greg (and others?) made a lot of improvements on PEAR.php to keep it as small as possible, plus using a bytecode cache makes it needless to worry about LOC.

On the other hand, gacl.class.php [2] is only 517 lines of code with comments, and it doesn't include anything, except:
- ADODB files ( /me wants native db support :( )
- Cache_Lite (from PEAR? hehe :), but in return I get caching

[1] http://cvs.php.net/co.php/pear/LiveUser/LiveUser.php?r=1.37
[2] http://cvs.sourceforge.net/viewcvs.py/phpgacl/phpgacl/gacl.class.php?rev=1.48&view=auto

#2.1 Norbert on 2005-02-02 07:38 (Reply)

I guess if you want to get technical, according to sloccount, gacl.class.php is 284 lines. Cache_Lite is definitely larger. ;)

I don't see this as a deciding factor though. The performance of the class itself is much more important.

phpGACL comes with a stress test suite (and unit test suite) that you can run as a quick and dirty benchmark. The hard thing though would be comparing apples to apples in regards to LiveUser.

#2.1.1 Mike on 2005-02-02 08:39 (Reply)

Lukas = LiveUser dev

Here is an interesting benchmark to look at. Eventhough it compares DBAL's it holds some general value when going at performance from the LOC perspective:
http://sourceforge.net/mailarchive/message.php?msg_id=10269486

As for the Admin API: LiveUser is for all I know now the benchmark in flexibility for any admin API you can think of. Its even possible to add whatever kind of other tables you have into it with little effort, since it builds all SQL on the fly.

As for performance:
We have session based caching and we have reworked things so that we can now easily add Caching. Our structure also means that you can trivially plugin other storage container layers. So for example adding a mysql native container should be a matter of about 1-2 hours max.

I personally had huge trouble grasping the phpGACL concepts, then again its not like all users immediately get how things work in LiveUser either ..

I did have a look at phpGACL both the features and the source btw. I spend about half a day looking at it. And it seemed to be quite nicely thought out. It has funky features like being able to add a user a virtual role based on how browser (to talk in the LiveUser terms). So its not like phpGACL is a subset of the features of LiveUser.

As for stability and beta state etc.
LiveUser has actually maintained a pretty stable public API for the client. The main things that changed were the containers behind the scenes and the config array. The RDBMS schema has also been very stable over all these years. The Admin API is now cleaned up and its was a huge mess before. I have used several different versions of LiveUser in production and upgrading was a difficult task mainly because with every release I was able to throw away more things that I had to do outside of LiveUser (like saving custom user information etc).

#2.1.2 Lukas on 2005-02-02 11:44 (Reply)

I was just wondering if you ever made a decision in regards to this. I am working on a Software Engineering class project, and I am faced with a dilemna of finding a good permissions framework to use. We are already using PEAR:DB because of it's nice integration with Smarty. I have never tryed ADODB but I also need other things such as some sort of Object-Relational Mapping since the professor is pretty insistent on using OO (we are primarily Java Programmers).

#3 Core.B (Link) on 2005-03-17 16:43 (Reply)

Don't know if this means anything to anyone, but Mambo Open Source CMS uses both phpGACL and ADODB as it's back end permissions / db layers, and I happen to know that they put a lot of time into choosing both!

FYI!

#4 Brad Parks (Link) on 2005-03-22 14:59 (Reply)

I'm searching for a reasonable permissions system for a project I'm involved and I must say this post and comments are one of the best information sources I've found on the subject after digging dozens of websites. :-)

Hmmm. Sorry for not adding too much to the discussion. :-P

#5 moraes (Link) on 2005-06-08 01:31 (Reply)

yah i agree with you on this one =)

#5.1 Anonymous on 2005-11-01 19:56 (Reply)

Glad it helped :)

#5.1.1 Norbert Mocsnik (Link) on 2005-11-01 21:51 (Reply)

This was a nice read, although somewhat dated as of now. I think phpGACL hasn't changed much if at all, where LiveUser has been developed further (this statement can be seen both as a pro and con to both LiveUser and phpGACL in a way).
I'm a little surprised no one has published a benchmark comparing both of these libraries.

#5.1.1.1 Michael on 2007-07-04 16:48 (Reply)

Once a permission system matures, it doesn't change much. When was the last time the permission system in Linux changed significantly?

phpGACL is still actively developed, but the feature requests/bug reports have nearly dried up, while its usage continues to steadily grow.

#5.1.1.1.1 Mike on 2007-07-04 17:07 (Reply)

Thanks Mike.
One thing I did not deduce from either LiveUser nor phpGACL was how to manage other users. I basically see how to set control on objects, but what if users are the objects? To be less abstract about it, can you specify control over users with either class (maybe like specifying what users can manage other users?).

#5.1.1.1.2 Michael on 2007-07-06 00:29 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	Enclosing asterisks marks text as bold (word), underscore are made via _word_. E-Mail addresses will not be displayed and will only be used for E-Mail notifications To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly. Enter the string from the spam-prevention image above:
	Remember Information? Subscribe to this entry

Calendar

Subscribe in a reader

currently reading

(More)

Monday, January 31. 2005

implementing a permission system for a WACT project

Calendar

Subscribe

Categories

Links

currently reading

Quicksearch