How to implement access control in Delphi?

Question

Delphi

Database in Delphi. It is required to make differentiation of access rights: a normal user and an administrator. At the moment, my program looks like this: at startup, an authorization form appears, and then the program itself opens and you can use all its features. Login and password are stored in the program code. How to implement this access control?

Answer 1

For a course project, it is enough to add a field to the users table that indicates the admin rights.
Roughly speaking - IS_ADMIN (INT).
After entering, you read this value and, depending on it, simply do not allow you to perform some functions. Either you hide the buttons and menu items, or you just check at execution whether the authorized user has the IS_ADMIN flag and otherwise you throw an error and abort the function.
This is an easy example to understand. It is enough for a course project. Making a normal role system is troublesome and often requires a backend that implements an API for accessing the database.

Answer 2

Create a "role" variable and bind it to the user.
Create two roles - admin and user, and check the role in all functions that are used in the table and determine the available functionality depending on the role.
Also make signs on the tables that will determine the possibility of recording depending on the role (here it's just a comparison of "admin" and "current user role").
Is it clear enough? I simplified a little. It would be possible to work out the roles, making it possible to configure them down to individual tables and functions, but this is much more complicated.

Answer 3

You need to think not about roles but about privileges. The right to read the table or tables (SELECT) the right to edit (UPDATE) the right to delete (DELETE). And the roles are already cosmetics that hierarchically builds privileges.
Based on the granted privileges, you decide what the admin is. with them (privileges) you can check exclusive access requiring the ADMIN_ACCESS privilege, for example. Thus the admin is the one who has the ADMIN_ACCESS privilege.
Simply put, there is some code that, by login-password, returns the IUser interface, which has a child interface object IRights, which has the function HavePrivilege(PriviligeID, ISecurityContext) where PriviligeID is some numeric or string designation of the privilege (which is hardcoded in the code and is used where necessary) ,
ISecurityContext - interface to the list of data access to which is checked, it can be anything:
- table
name - component name
, etc.
Suppose you are designing a loan application form, there are 2 roles:
- an administrator who sees all applications in the system, from all operators and can delete them.
- the operator who creates them, edits and sees only those applications that he created himself.
The system of rights:
There is a concept of privileges, if we speak within the framework of operations with the database, then the privileges can be:
- indicating the tables that are allowed to be accessed.
- with an indication of the sign of a super-privilege, such a privilege stupidly has access to all tables.
- with an indication of a pre-installed filter, for example, a request for data from a table will be generated with reference to the current authorized user, and the user will see only those records that he himself created.
Actually you have 2 forms:
- 1. Form with a table of applications.
- 2. Application form.
The logic is this:
A form-list of statements is opened, the TABLE_READ permission is checked, if it is not there, a whack with the message "You do not have rights to view this data." The user sees an empty grid and a close button.
If there is TABLE_READ, and there are NO "CreditRequests" among the tables specified there, then the same whack with a message.
If TABLE_READ is available for this table or it is a super-privilege to read all tables, then we look at the filter, and apply it to the generated SELECT. What is a filter?
The CreditRequests table has an OperID field that points to IUser.ID i.e. associates a record with its creator, so through the privilege of opening a table with a filter, you will show the user only the records that he himself made.
Then the database opens, with the formation of a sample and display in the grid.
Further on the form is some ActionList , where TABLE_EDIT, TABLE_DELETE are checked in a similar way for inserting, editing and deleting records, i.e. if IUser.IRights answers that there is no such type or not for the requested object, then a cuff with a message about lack of rights.
Thus, the administrator will see all applications and will be able to look at any tables, because. has all the privileges without restrictions.
The operator will see only the table of loan applications, see only his own applications, and only they can be edited and deleted.
This rights system is complex and is usually deeply integrated into display components in particular. for example, the operator sees the columns (fields) of the table entry, and the administrator must see and be able to filter the data in the context of the operators that generate the requests, i.e. there is a column that raises the full name of the person who created the request from the database + you can generate a change log for the request (who changed what and when), the verification mechanism is also built in here, i.e. the operator created, the admin accepted / refused, the application for revision was returned to the operator.
And sometimes the distinction goes even deeper, for example, it is allowed to edit only some components on the form (for example, put marks / checkmarks or write notes).