This is a nice approach except that I think you will end paying a high penalty for just iterating through all controls (labels, splitters, panels, etc). That's probably why I suggested the IExtenderProvider as a method of extending the controls to be "security aware".
> Note also that no matter what security related stuff you do in the UI, > you'll also need to check everything in the business layer too. Hiding > or disabling a control provides no real security at all, you'll have to > check the authorization again in business code. Totally true!. In my original post I also raised this issue: an elegant way to handle security permissions in the BLL. Suppose you have complex roles hierarchy this can also get messy. The quickest solution that comes to my mind is to use AOP since security is not really a business concern. I don't want my AddClient() method to know about roles or permissions. The responsibility clearly belongs to a different class. I've read something about the mechanisms that .NET has to decorate methods with security attributes but haven't used them yet. Maybe a visitor pattern could decouple the responsibility in this section better than in the UI. -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Sami Vaaraniemi Sent: Monday, January 10, 2005 10:23 AM To: [email protected] Subject: Re: [ADVANCED-DOTNET] Architecture question on security and permissions I had to do something similar in a project I worked on. The situation never got really complex so I got away with just coding the UI-centric business logic case by case in my form's initialization code. Essentially: adminOnlyButton.Visible = user.IsInRole("admin") etc. I've thought about this problem since and if I had to do it again now, I'd probably do something similar to the Visitor pattern. I would decorate controls with custom attributes like so: [RoleRequired("admin")] protected Button AdminOnlyButton; I'd then have another generic class that would use reflection to go over controls in a form and based on current user's role and the attributes attached to the controls, it would show or hide or disable the controls as appropriate. So the real work would be to code this generic class and after that you'd just attach attributes to controls in forms. Note that this is only an idea so I'm not sure of how feasible it would be in really complex cases. Note also that no matter what security related stuff you do in the UI, you'll also need to check everything in the business layer too. Hiding or disabling a control provides no real security at all, you'll have to check the authorization again in business code. Regards, Sami > You said "I would just put the conditions direct in > the form." > > In my previous project this was a pain to implement so hence one of my > questions. I used to have a form showing a list of all Clients and then a > form with edit functionalities. The issue was that in order to edit or > delete certain clients you had to had certain security attributes that > related to other business rules, per example, if the user was the Store > Manager or Company Admin. So the logic of allowing the user to edit or > delete was based on the client and other complex rules that made more sense > as a Business rule rather than strict UI logic. > > I was unable to find a satisfactory solution so ended up doing what you > propose but found myself very quickly having a complex "if then if" for all > the special roles. > =================================== This list is hosted by DevelopMentorR http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor� http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
