Fog Creek Software
Discussion Board




how to handle user permissioning?

how do you handle user permissioning for GUI? Ie if a user group or individual user shouldn't have access to a certain area of the program OR access to a certain control.

i have thought about the facade pattern. i've also thought about some sort of meta-data layer.

thoughts?

Patrick
Tuesday, August 24, 2004

My permissioning system is based on three entities:

* the id of the user
* the id of the object being operated on
* the type of operation (delete, rename, view, ...)

I have a method that accepts these three things as parameters, and that retruns true or false depending on whether this user can perform this operation on this object.

I call this method just before invoking the specified operation on the specified object (so that I can decide to not perform the action if necessary).

I may also call this same method when deciding whether to enable or disable GUI elements.

Christopher Wells
Tuesday, August 24, 2004

good idea Chris. You're very helpful.

where do you put this "method" ?  something tells me it isn't in each form. do you have like a "user permissions" class?

Patrick
Tuesday, August 24, 2004

Do a search on role-based security. This will give you some starting ideas.

Just me (Sir to you)
Tuesday, August 24, 2004

Thanks.

It's a static (global) method ... a member of some kind of Facade class. The permissions subsystem is fairly large with many implementation classes (to cope with user groups, object groups, editable (assigned and saved and loaded) permissions).

It's not a member of the form. If you think of Model/View/Controller, where View invokes Controller which invokes Model, and where the connections are acyclic (i.e. View invokes Controller but not vice versa) then the permissions system is in the Controller: because permissions are checked by the Controller before the action is run (as well as being invoked from the View which decides which GUI components to enable).

Christopher Wells
Tuesday, August 24, 2004

I use groups (established user table), I have 4 groups, each user fits in just one of them ... than every form/GUI has a group level access check, thats how I control what the user group can or cannot see.

Raju Patel
Tuesday, August 24, 2004

I have similar permissioning in my app but long time ago
I lost control over it. It is too complicated and I need
to rewrite it anytime soon cause adding features became
near impossible for me.

In there are things like "this guy shouldn't be able to do
this, unless he sits on this computer and/or his boss is
sick/on vacations".

No wander that in real world everybody knows everyone
else's password.

VPC
Tuesday, August 24, 2004

We also fold in a novice/general/expert setting
which allows extended functionality (expert) or automatically fills in default values (novice)

Martin Beckett
Tuesday, August 24, 2004

In a GUI app, I like to download the user's permissions when the application starts up and then enable/disable menu options. That saves me the trouble of poping "not authorized" message boxes later. (If the user isn't authorized, the relevant menu items and buttons are simply unavailable.)

Tom

Tom
Tuesday, August 24, 2004

"(If the user isn't authorized, the relevant menu items and buttons are simply unavailable.)"

Most cases I run into you'd be better off not displaying the elements entirely. That way users don't get the idea they are missing out on something. They won't nag you about 'hey I want menu item X!' just because they saw it disabled.

OT: The phpGacl project  (http://phpgacl.sf.net) has a nice model:

- ARO's (things that can request access, e.g. users or an external system)
- ACO (things that need access control)
- ACL (stating that ARO X should be able to access ACO Y)

Each of these have a grouping: you can fold several ARO (users) together into an ARO group. An ARO can be a member of multiple ARO groups. An ACL could couple an ACO to either one or more ARO's and/or ARO groups.

Then there is a fourth elemen, an AXO. This would mean something like an item. If you pull everything together into normal english: "Usergroup 'developers' (ARO) should be able to 'add new documents' (ACO) to the 'FUBAR project' AXO".

Succes!

Jilles Oldenbeuving
http://www.jillesoldenbeuving.nl

Jilles Oldenbeuving
Tuesday, August 24, 2004

*  Recent Topics

*  Fog Creek Home