That's similar to what I do.
In addition to using Windows security for authentication, I have my own
roles that one can be assigned to, which is stored in a SQL table.[2]
In my class which is the base class of an inheritance structure, I have this
sort thing to determine if commands are visible or enabled based on role [3]
However, I ended up not being pleased by this because changes to the
business security rules required changes to the code. So what I did was
create a table of commands in SQL and in my application I dynamically build
menus/btns from the output of queries on the command table which take into
account the role of the user. [1]
[1]
CREATE TABLE [dbo].[AppCommands] (
[rowguid] uniqueidentifier ROWGUIDCOL NOT NULL ,
[KeyName] [nvarchar] (50) // Keyname is the key of the UI control.
I'm using 3rd party UI that have this property
[CaptionName] [nvarchar] (50) // Text on the button , etc
[IsRoot] [bit] NOT NULL , // Should be the top most menu item (File,
Edit, Window, etc)
[ChildOf] [uniqueidentifier] NULL , // rowguid of the command under
which this should appear
[OrderPosition] [int] NULL , // ordial position of the command in
the list
[DoesStartGroup] [bit] NOT NULL , // determines if a seperator
should appear above this item
[ForAll] [bit] NOT NULL , // Role
[ForRep] [bit] NOT NULL , // Role
[ForMGT] [bit] NOT NULL , // Role
[ForBPS] [bit] NOT NULL , // Role
[FormName] [nvarchar] (100) // If command is to open a form, name of
the form for dynamic invocation
) ON [PRIMARY]
GO
[2]
protected void SetSecurityNames()
{
// Send Enviroment.UserName to db to get dynamic
list of Roles.User can be in zero or many roles
StaffBusiness sf = new StaffBusiness();
string[] roles = sf.GetRoles(Environment.UserName);
FrameworkBase.UserRoles = roles;
gPrinc = new GenericPrincipal(currentUser,roles);
FrameworkBase.GPrinc = gPrinc;
}
[3]
if (gPrinc.IsInRole("MGT") == true)
{
commandVesselFunctions.Enabled = true;
commandVesselFunctions.Visible = true;
...
}
if( gPrinc.IsInRole("BPS") == true)
{
commandVesselFunctions.Enabled = true;
commandVesselFunctions.Visible = true;
commandCargoOwner.Enabled = true;
commandCargoOwner.Visible = true;
}
CC 1A 5B 94 D0 75 09 B4
USA USA USA USA USA
http://www.vinnychi.com/vince
Did you think that I was gonna give it up to you?
> -----Original Message-----
> From: Unmoderated discussion of advanced .NET topics.
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Sami Vaaraniemi
> Sent: Monday, January 10, 2005 7: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
