Geek Answers Handbook

User Interface Elements Authorization in .NET WinForms

I have a general question about the best approach to authorizing user interface elements for application roles. I mean that the Administrator can see buttons, menu items, etc., which the average user can not see. What is the best practice for this?

I understand that there may be several role-based screens (admin screen, same screen duplicated for the user, etc.), which definitely seems redundant. I also want to keep the group split, so my authorization code does not mix with the display functionality. In other words, I want to avoid:

if( current_user.IsInRole("administrator") )
  button.Enabled = true;

I looked at Aspects with PostSharp, which seems almost what I want to do, but it doesn't seem to extend logically to the user interface.

I'm sure something is missing for me, what is it?

Thank -

+5
source share
1 answer

It seems likely that your code will eventually compile a list of user interface elements to hide or perform this action, and then perform these actions based on the current role. Sort of

Dictionary<Control, Action<Control, string>> actions = new Dictionary<Control, Action<Control, string>>
{
    { button, (c, r) => c.Enabled = (r == "administrator") },
    // etc.
};

How you compile this list is primarily your question. AOP structures definitely help in sharing problems, but resolving homebrew will not be impossible. I think something like:

  • EnableForRoleAttribute role.
  • (, , , , , RoleVaryingAttribute ).
  • , Control, Control EnableForRoleAttribute.
  • ! Enabled .

Enabled, , lambdas :( SetPropertyIfInRoleAttribute role, propertyName propertyValue .

, AOP , PostSharp , . homebrew .

+5

More articles:


All Articles