In order to install a fresh application, it is important to initiate user tables, mostly because passwords depend on an encryption key which should remain unique for each of the applications deployed.
By default, you should copy the /Scripts/ directory which contains a script to add users to the system. There is also a script to generate new encryption keys that should remain internal to the application. You should ; 1) adjust your main options in the configuration file admin-conf.php, extranet-conf.php and www-conf.php (the paths must be functional and the name of the application configured under SYSTEM_FLAGS ["App_Name"]) , then 2) execute the Generate_newCryptoKeys.php script which will give you an output to copy and paste into your configs. You must replace the lines concerned (easy to identify from the output of the script).
Thereafter, you will be able to create users and configure passwords that will be validated.
Passwords are stored in the SYS_User.Pswd_Hash field, hence the SYS_User tables no longer contain the decrypted field Pswd, or the encrypted field, Pswd_Crypted. (Poor security practices, expired in May 2020 in the code for mental health reasons)
To store a password, it is mandatory to produce a hash with the function:
CORE\SodiumCrypto::hash_Password (strongstring $ Password)
To validate a password, you have to rely on the function:
\CORE\SodiumCrypto::Password_Match ($ storedPassword, $ submittedPassword)
Consult the blog "Use of encryption with Core infrastructure" for a better overview of encryption (and incidentally, hash techniques)
Small list of tables involved in basic security management of interfaces produced from CORE.
Table Description
SYS_User contains the users of the application, both Intranet and Extranet.
SYS_Group contains the groups defined in the application. There should always be a # 1 group to represent the owner of the application.
SYS_Group_Users the mapping of users by group. Note that the SYS_User record contains a "main group" field which should normally be linked to an owner group (such as group # 1). The 2 (the SYS_User field, and the group membership lists) are frequently used in the system for managing ACLs and permissions.
SYS_Site contains definitions of sites for the management of sites, pages, cms, seo etc. It is unfortunately very necessary to populate this table to initiate an application in a clean way with the management of files which must be "mapped" of a some way to the web environment, Intra and Extranet. This table makes it possible to define more than one site, and more than one type of site, and is then re-used for the management of modular permissions. (The why of the obligation). In the near future, it is not inconceivable to build an installation script which will initialize this table properly during an installation or refresh.
SYS_Config Configuration by module stored in the DB, on first generation (for any user) of the menu contained in the basic skeleton (be it the boxlid_menu or the header_menu). The concept is that the system is led to management via BD, but still supports module.cfg config files in the directories to allow portability of modules between applications (copy & paste the module / and zoup!). Once a module in the DB, the user has access to additional options that would not be found in the module.cfg (for the moment ...). To "resetter" a menu (following a change in a module.cfg for example), the simplest way is to erase the contents of the whole table. (@todo: we could provide this option in the application management tools, to come).
SYS_Access table of ACLs by Group / User for each Module, and prioritized. Management is done via the Backend / Permissions / module, and would be very difficult to complete manually via SQL for hierarchical compilation. (Management is done so much better in graphical mode with a semblance of organization with groups and users.) It is always possible to erase the contents of this table to re-initialize the permissions of a system.