Hello all,
I am working on a web app. It has initial password security but I need to limit the menus/forms that the user can see, based on their login credentials. Does anyone have any sample code, ideas or any other information that may be helpful in this endeavor?
Thanks,
Tim
in the user table/database you could add a new column for permissions/role, or new table with a link.
after login you could store this in the session or extra class made for single user.
to control the ui use this class
if user.IsAdmin then
if user.IsStaff then
to make the app more secure you could add the user in a class constructor
and raise a error if he not have the permissions to use.
or just by name if login was successful
CurrentUser = new User("Tim Seyfarth")
it could set a boolean flag/propertie .Admin=true based on the name.
if someone can add a user account, give him minimum permission and a note to admin.
I hope Iāve understood your question correctly!
I have two database tables for this: Groups and Roles.
Groups are arbitrary for sets of users. Every database tableās record by default has no access to any Group, only the user who created it, but if a Group is assigned to this record, all members of that Group can access that record.
Roles are arbitrary access rights to application functions, and are assigned to a Group (see above). By default only the host/admin can āseeā all windows in the app, and no other user can see anything. When a CoHost role or accounts or HR role is created, more options āappearā for them when they log in.
This might mean that a user has a Group right to access a record, but they cannot access it because they cannot āseeā the button or window that gives them access to that record due to a lack of Roles.
If a user is a member of more than one Role, and one Role gives them access to a feature, but another Role does not, then they DO have access to the feature.
You might need to add granularity to the Role or Group ie they can see the window and the record, but can they edit it, delete it, create a new record, etc. In my case the Role also potentially gives access to all records in a table without the need to be the owner or assigned access in a Group, and I donāt add this level of granularity.
Groups
Roles
Thanks guys!
The Group/Role/User is what I used in the past. The big PIA is having to create some type of control over each form, or group of formsā¦ etc.
Thanks, again!
Tim
Iāve also used Groups & Roles, when it comes to sophisticated applications. It offers the most flexibility.
But if the security requirements are not complicated, there is always the simple ālevelā approach, using a single enum type property.
Start with defining an Enum called something like SecurityLevels, like:
Administrator_CEO = 100
Admin_Staff = 90
VP = 70
Executive = 40
Manager = 30
User_Staff = 20
User_Contractor = 10
Then just place an If statement around the things you want to hide or show, something like:
If UserObj.SecurityLevel >= SecurityLevels.Manager Then
// show or enable more important stuff here
End If
Note: I found if you space out the numbering between levels, it helps when you need to create a new level in the future, in between two existing ones, e.g., HR = 35
Also, on the user record, you now only need to store a single integer value as opposed to a one-to-many relationship for groups & roles.
to give each control a permission or make it visible or not, editable or not make the
gui very ugly.
and filigree design is very time-consuming.
for minimum permission i would use read (can view) and write (edit/change) for each form.
security level
users could have many areas of responsibility