Granted, I do it the old-fashioned-bigger-hammer method - but I put the code for security checking at the form level in the form init method. This is, of course, assuming that the customer has the security to get to the screen. That security is handled at the menu level. Security rights are held in a table with the userid as logical flags.


>OK, I'm out to learn from others' experience.
>
>Has anyone out there implemented field level and control level security in their application or framework?
>
>I've got an idea on how it can be achieved, but want to see if anyone out there has better ideas.
>
>
>My plan:
>
>

> 1) Each form has a Security object (custom) that will check the user's security level.
> 2) Each control that wants to be secured has a .SecurityLevel property that defines the lowest level at which it can be active.
> 3) Each control that wants to be secured has a .Secure() method that will take the appropriate action, either making it readonly or disabling it.
> 4) Each control that wants to be secured is responsible for calling THISFORM.Security.Guard(THIS)
> 5) The Guard() method in the Security object will check the passed object reference security level and then call the object reference.Secure() method if appropriate.
>

>
>This is almost a strategy pattern, except the strategy is inside the object being visited instead of being a separate class.
>
>I think that the levels could be loaded from a table at Init() time if the security is to be dynamic without recompiling the applicaiton.
>At present the client only wants levels 0 (nothing) to 3 (everything) but I want to avoid hard coding.
>
>Thus a table that stores the hierarchy of the object, and its minimum security level is needed IMO.
>
>
>Whaddya think?