A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I've designing a permission system in C#, and I've been thinking about how to implement the object model. I want it to be clean syntax, but also fast, and I think they are kind of competing in my design.
Without going into unnecessary detail, let's just say there is a Permission Set that a logged in user will have, that other objects can check to see if the user has permission to access certain methods.
For objects that need fine grained permissions, there is a PermissionObject abstract class. Let's say we have a Report object, and Report objects need to be able to control whether a user can Save a report or not.
Report therefore inherits from PermissionObject, which implements a "CheckPermission" protected method.
In the code, I can call myReport.Save(), and ideally, without any additional work, the base class will monitor the child method call and verify that the user has permission to make it.
The Report Save method may look like this:
public void Save()
...save object to persistence medium...
Based on the method attribute "PermissionMethod," the base class knows to fire its "CheckPermission" method which throws an exception if there is no permission.
That's the idea, but I'm not sure how I could implement such a thing? Maybe set up a Delegate within the base class, and upon initialization of the child class, register events for each of the permission methods? I just don't know.
Alternatively, I could simply call base.CheckPermission(); at the beginning of any method I wanted to respect the system. I'd rather not because it's ugly, but if I have to do that, it brings up some other questions:
I know I can theoretically figure out which object type and which method were called through reflection, then check it against the permission set, but I don't think that will perform well. What is the best way to cleanly get this information without massive overhead?
Monday, April 21, 2008
Personally, I reserve Inheritance for "Is-A" relationships. Since a Report is not a "Permission", inheriting from a Permission object wouldn't be appropriate.
Now, a Report "Has-A" permission property -- but then you have two halves of the problem.
Namely, each Report "Has-A" "Role-Allowed-To-Print". Each Person then has a "Permission-role-they're-assigned".
So, if a Person "Has-A" particular Permission level, then they can send their "Permission Level" to a Report object on Print-Request. The Report object can then check its "Permissions-Allowed" property compared with the Person-Permission passed in to know what this Person can do.
I think trying to use Inheritance in this situation confuses the issue.
Monday, April 21, 2008
Yeah, I know what you mean. It does seem like I'm reinventing a bit of a wheel here, but there are certain specific requirements I have that the .NET security stuff can't handle, and they aren't "nice to have" requirements, they are necessary for the business.
I appreciate the feedback though, have a good day!
Tuesday, April 22, 2008
Perhaps checking the discussion about the Role pattern from the java forum will help:
I'm having the same problem and still I'm not pleased about what I've done but the link above helped me, anyway.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz