Question

I am implementing an infrastructure for access control of models in a web application. The library has a context class that controllers (and maybe views) use for determining if the current user has access to a certain object. For keeping relevant information close to the target object, I’ve decided to pass on the access check request to the models themselves from the context object.

Implementing this mechanism for model object modification is almost trivial. Declare an interface, say, ICheckModifyAccess; and implement it in your model. The same goes for delete check. In both these cases, it is possible to ask an instance of a model whether it is OK to modify or delete them.

Unfortunately, it is not the case for read and create operations. These operations require that I ask the question to the model class. So using an interface for this is not an option.

I ended up creating an attribute, CheckCreateAccessAttribute, and then ended up using this attribute to mark a static function as the interface function. Then, in my context object, I can use reflection to check if such a marked function exists, if it matches the signature I expect, and eventually call it. In case it makes a difference, the method for create access check is public bool CanCreate<TObj>();. A typical model that supports access control would add something like the following to the class:

[CheckCreateAccess]
public static bool CanCreate()
{
    return true;
}

I am not very fluent in C# yet, and I have a nagging feeling that I’m doing something wrong. Can you suggest a more elegant alternative? Especially, can you get rid of examining TObj by reflection?

Answer 1

It sounds like you’ve combined concerns in your object classes instead of separating them.

The temptation to “keep relevant information close to the target object” has perhaps led you to this structure.

Perhaps you could instead handle permissions in a separate class, see for example this article.