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. -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Ben Kloosterman Sent: Sunday, January 09, 2005 10:37 PM To: [email protected] Subject: Re: [ADVANCED-DOTNET] Architecture question on security and permissions Sorry mistook you for a more general discussion on client middle Tier security. In nearly all cases I simply return an access code in a user class when the user logs in . This has an int with bits for varies systems. I use an enumeration for this ie enum Rights {Account_Rights , Account_Admin_Rights ...) ; The UI can then hide the buttons , as it is more UI logic than business ( ie not display the buttons) I would just put the conditions direct in the form. If the user has no rights to middle tier then he can not logon , so only system users can login . The only real flaw is someone internal can hack the DB or middle Tier direct, with the information from earlier packets but this is painful to avoid (which is what I was sort of getting at in my last email ). Regards, Ben > -----Original Message----- > From: Unmoderated discussion of advanced .NET topics. [mailto:ADVANCED- > [EMAIL PROTECTED] On Behalf Of Roni Burd > Sent: Monday, 10 January 2005 11:59 AM > To: [email protected] > Subject: Re: [ADVANCED-DOTNET] Architecture question on security and > permissions > > In my case I'm starting a project form scratch, so I have no legacy system > to deal with. > > What I was asking are solutions in both enterprise internal and client > code. > Let me give a few examples: > > Imagine a WinForm app where you have CRUD operations for Clients. > Depending > on how the user logged in, he will be able to see the Save or Update menu > or > button. My thinking was having an interface or implementing > IExtenderProvider on all the controls or menus to show them or not. > > Also for security reasons, a way to ensure that BLL.Clients.Update() can > be > executed by a user or not. > > So what are you're experience? > > > -----Mensaje original----- > De: Unmoderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] En nombre de Ben Kloosterman > Enviado el: Sunday, January 09, 2005 7:35 PM > Para: [email protected] > Asunto: Re: [ADVANCED-DOTNET] Architecture question on security and > permissions > > Depends what you are talking about > > Enterprise internal , client connected systems or internal . > > I find in most cases most developers and admin guys don't understand and > stumble through even basic security policies and productivity breaks > down. You also have to remember in most enterprises you still have > clear passwords going across the wire in a lot of UNIX/ legacy systems. > In most organisations anything else is pointless until these and , weak > passwords and dbo / admin accounts on databases are fixed. > > The web site and client connectivity is a different kettle of fish. > Though current practices are adequate. > > Getting into detailed .Net security is beyond the need of most > organisations, why fix a small pipe when the dam is already open. In > most cases if you get the basics right across your organisation you are > in a better position than trying more complex ones. > > > Ben > > > -----Original Message----- > > From: Unmoderated discussion of advanced .NET topics. > [mailto:ADVANCED- > > [EMAIL PROTECTED] On Behalf Of Roni Burd > > Sent: Saturday, 8 January 2005 11:26 AM > > To: [email protected] > > Subject: [ADVANCED-DOTNET] Architecture question on security and > > permissions > > > > Hi, I'm in research fase of a modest size enterprise application. I've > > programmed a lot with .NET before but was never quite satisfied with > the > > way > > we were dealing with security and permissions and I wanted to ask you > guys > > for your experience. So here go some questions hoping to start an > > interesting thread. > > > > > > > > I've been reading about class access and method access security using > > "Security Demand", "Security Override" and "Security Optimization". > How > > good > > are these methods and how painfull it is to implements them across my > BLL > > and DAL. > > > > > > > > Also I've been wondering for a long time how people manage the UI. Is > > there > > a way of decorating controls (maybe IExtenderProvider) so they can > disable > > themselves when the user is not allowed to view them, or maybe > disable. > > Think menus, buttons, hidden fields, etc. > > > > > > > > Finally how does Authorization and Profile Application Block fits into > the > > picture and what experience you have using it (tips, things to be > careful > > of, etc) > > > > > > > > As you can tell, I'm really newbie when it comes to .NET security > using > > functionalities that are provided in the framework. Also I haven't > been > > able > > to find articles describing security these features. > > > > > > =================================== > > This list is hosted by DevelopMentor(r) 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 > > =================================== > This list is hosted by DevelopMentor(r) 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 =================================== This list is hosted by DevelopMentor� http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
