|
As to item "B" that proposal violates one of the basic rules of
database
design: Storing sets of data in one record. If I were designing this security application I'd have a file keyed by UserID, MenuName, and
Option#
and have one record for each option. If the record doesn't exist then
the
user wouldn't be authorized to the application. As an added feature, if
the
record exists you could check an authorization code to see what they're allowed to do in the program (change or just display).
We do something like the above suggestion, but in our case the key is 'option identifier', group profile, user id. The group is checked first, then the user name if a group doesn't match. This is nice because it is easy to allow all tech support staff access to (almost) every option for troubleshooting. For each record there are a bunch of flags that can be used to refine access as suggested (add, delete, display only, etc). Most of the time the 'option id' is a combination of the menu program name and the menu option number - but may be a program name if that program has specific internal security requirements like the add/delete/display type of thing. The only thing I've found is that it can get a bit frustrating to hunt down the 'option id' if a manager calls a says 'Can you give Adam access to option 15?'. We have built some tools to show all of a user's authorities, add a new user by copying an existing profile and that sort of thing which helps somewhat. It is also somewhat of a challenge to keep up with changing authorities when job functions change - I think this might be alleviated with better use of group profiles. HTH, Adam ##################################################################################### Attention: The above message and/or attachment(s) is private and confidential and is intended only for the people for which it is addressed. If you are not named in the address fields, ignore the contents and delete all the material. Thank you. Have a nice day. For more information on email virus scanning, security and content management, please contact administrator@xxxxxxxxxxxx #####################################################################################
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.