After inserting some new fields to my users table, I almost accomplish all my primary requirements concerning functionalities for user management.
Firstly, my Admin toolbox has a Roles box where administrators can list roles and manage them. As my roles table is extremely basic, this box is rather straightforward to use.
The Admin toolbox also includes a Users box. Administrators can place this box on a screen in order to display registered users. In addition, this box gives access to users’ management where authorized users can create new user, change account information and assign them to roles.
My Users box is an enhanced version of the IBuySpy one. First, it can generate random user id and password when administrator let one of them empty. Second, it allows filtering of users according to selected roles. This way, an administrator can easily visualize users and roles association. In addition, this box contains a DropDownList control filled by users that quickly assigns a user to selected roles. Third, another DropDownList operates as a filter for users according to their last login date. This discriminates users that did not access since more than 3 or 6 months and gives a method to remove them in one click.
For final user, I have a Login box, where each registered user can give his user id and his password when he needs to access to protected screens. This Login box also provides a reminder password box. Here one can give his email address and whether he is a registered user, he will receive an email with a new random generated password. As passwords are stored as a MD5 non-reversible encrypted string, I cannot send original password.
When authenticated users would like to change their password, I build a Password box with the standard three fields (old password, new password and confirm password) and a “Save” button to apply their new password.
There is an auto-registration box where one can give his email address and his name. If his email domain belongs to an authorized domain, a new account will be created with default roles and the new user will receive an email with his account information. This kind of registration will be useful for intranets.
Later, I will complete my LDAP integration tests. In a first time, my intention is to check authentication according to my users table and then control it against a LDAP server.
- Authentication is ok with database and ko with LDAP => it’s a “local/private/temp/multipurpose…” user account,
- Authentication is ko with database and ok with LDAP => create a new account in users table according to LDAP data and with default roles,
- Authentication is ok with database and ok with LDAP => update account according to LDAP data.
Of course, when a user will exist in LDAP, I will not store his password in database. Therefore, an empty password will denote a LDAP user. Presently, I will associate users to roles in database. Utilization of LDAP groups to generate roles will come in a far far away time.
But now, I have to revise my SQL scripts and to update my monoforge demonstration. Next, I need to make some tests before updating the Access version.