Major bug fixes relating to the Redis implementation in Reprocessing and Search Key Cache were identified and fixed as part of the rekeying development. Included functionality to stop the Exhaustive training. Fixed the Unsupervised learning functionality in Exhaustive Training. Embedded the Mock Data CSV data into a class to make it compatible with Docker without needing to modify the Dockerfile (i.e, build). Included a new table that stores training data to enhance support capabilities for Exhaustive. Reintroduced and validated the Multitenancy functionality. Postgres is now fully deprecated in place of Redis for cache, and all implementations of the Interfaces for Postgres have been removed. No migrations exist to support this deprecation, and Postgres as a cache is now wholly unsupported. Removed the Indexing background thread, as Redis does not require it, given that it is a key-value pair database. Created a RedisCommandFlag Environment Variable to support Fire and Forget write to Redis in Invocation. Implemented functionality to Export, Peek and Download configuration environments using a secure, encrypted scheme. Created a permission to access the functionality via the user interface. Extensive database-based logging is included to provide for a comprehensive audit. Created functionality to Import the encrypted Export file inside a database transaction to ensure consistency. As Docker is now the primary deployment model, log4net instantiation has been moved to an approach that primarily uses programmatic instantiation of the ConsoleLogger and RollingFileAppender given Environment Variables. Implemented functionality to support remote \ mounted Log4Net XML Serialisation files for more advanced log4net configurations. Reintroduced access to counters via the user interface and created a permission. Took the opportunity to implement ReSharper linter suggestions. Disabled the Lock button across the whole application, with that functionality being reserved for future use. It is intended that locking happens programmatically on the basis of dependencies in future commits. Fixed several significant end-use bugs which became apparent during testing of the refactored code relating to case management and visualisations. Fixed certain other minor bugs that came up during testing. Brought documentation up to date for this commit. Brought the Docker Compose file up to date for this commit. Removed Redundant Environment Variables for this commit. Made the README file less verbose and unnecessary.
4.0 KiB
layout, title, nav_order, parent, grand_parent
| layout | title | nav_order | parent | grand_parent |
|---|---|---|---|---|
| default | Users | 4 | Administration | Configuration |
🚀Speed up implementation with hands-on, face-to-face training from the developer.
Users
All user interactions in the user interface are subject to authentication and authorisation. Authentication rooted in a user account, which is more often than not accompanied by a password (keeping in mind the software also supports JSON Web Tokens for authentication).
Users are allocated to Roles, which serves to consolidate authorisations upon authentication (in the form of permissions).
To create a user, navigate Administration >> Security >> Users:
The tree will present a list of Roles available. Click on the Role for which the User is to be created:
In addition to the Name, the user has the following properties:
| Value | Description | Example |
|---|---|---|
| Role | The role to allocate the user to, defaulting to the role selected in the event of new user creation. The drop down list is available in this manner to facilitate the moving of users from one role to another. | Administrator |
| The email address of the user for system communications. | [email protected] | |
| Password Locked | A switch indicating is the password is locked. | False |
Complete the page for a new user called Test as follows:
Scroll down and click add to create a version of the User:
When the user is created no password is allocated and it is considered locked.
In the background a password is maintained using the Argon2 hashing algorithm. A separate process to create a password, store it securely and then unlock is available via the Get Temporary Password button:
Click the Get Temporary Password to present a randomly generated password for communication out of band to the user:
The password is set to have expired, which will force the user to change the password on first attempt at authentication.
To test the user account, make a note of the password and navigate to Account >> Logout:
Logging out clears the JSON Web Token from the header and cookies, and accordingly all resources will be unavailable until a new one is in place, requiring authentication. Complete the authentication page with the new user Test alongside the temporary password:
Click Logon to test the temporary password and be forced into change:
Upon change of password, the permissions will be afforded as the role the user was allocated to, in this case administrator.
An authentication journal is available in the database which logs successful and unsuccessful logins, the local IP, the remote IP and user agent of the browser. The audit is available via selection of the UserLogin table:
select * from "UserLogin" order by 1 desc
Returning the following data:
In the event of all users having invalid credentials, the Command Line Interface (CLI) will need to be used to reset the Administrator password. The CLI is documented separately.









