Requirements
To be able to create and edit users, one must either have a role with the system permission "Administrator". Beginning with DeskClient 4.17.0 and Server 4.17.0, the document type permissions to read, create, save, publish and set offline for user documents are sufficient. In addition, the read permission on roles is required. To be able to change user settings of other users, the read and write permission for user setting documents is required. Users without administrator permission may not edit other users with administrator authorisation.
Creating a New User
- Open the view Administration
- Go to User Management >> Users
- Open the context menu and select New: User
- The 'New document' wizard opens. Choose a structure node preferably under /system and id stem. You can simply keep the defaults. Press Finish.
- An empty user editor opens. Enter at least a Username and a Password. Those fields are mandatory.
- Though it is not mandatory, you should also assign him at least one role.
- Save and publish the user.
Editing a User
- Expand the entry Users within the administration view.
- Double-click the user you want to edit.
- The user editor opens, where you can edit the user according to your wishes.
- Do not forget to publish the user, when you're finished.
The User Editor
The user editor looks like the one you can see in the screenshot on the right. You will learn more about the functionalities later on. First, you will see the input fields Username, Password, and Repeat Password. Those fields are mandatory for every user. After you have created a user, the field Username cannot be changed anymore and becomes read only. You will learn more about the field Password in one of the following sections.
After that, there are a few text fields and checkboxes also concerning your password settings, followed by some input fields for personal information about your users, like first and last names or their phone number. On the tab Meta are some meta informations about the creation and modification of the user document.
In the box Roles, you can assign one or more roles to the user. The user can only log in to your system, if he has at least one role; without any role, the Sophora server will deny a connection.
Users With Multiple Roles
A user who has multiple roles is permitted to execute all actions, that at least one of his roles provides to him individually due to its permission configuration. However, permissions are not merged. We should give you a few examples:
Role A may read story documents at structure node X; role B may create story documents at structure node X. Thus, a user with both roles A and B may read and create story documents at structure node X.
Otherwise, consider that role C may read story documents at structure node X, while role D may create image documents at structure node Y. A user with both roles C and D may neither create story documents at structure node X, nor is he able to read story documents at structure node Y or create image documents at structure node X.
Setting up a Password
Due to security issues, every Sophora user account must be secured by a password. Hence, the field password is mandatory for every user document. If you create a new user, you have to enter a password for him or her in that field, and confirm it by entering the same password again in the field Validate password. If you save the document, both fields will be flushed. This does not mean the passwords are lost; they are still saved in the background.
If you want to change the password for an already existing user, just enter a new password in both fields. After you published the user document, both fields will show stars, but the new password is now the valid one and has overwritten the old one.
Password Rules and Validation
To ensure all passwords meet a certain security standard, you may define a regular expression, that all (new) user passwords have to comply with. For this purpose, you have to specify a regular expression in the configuration setting user.password.regex. Additionally, you may also add a description for this regular expression, which will be shown to those users who enter an invalid password (one that is not consistent with the regular expression). Just enter such a description in the configuration setting user.password.regex.description.
For a thorough synopsis of possible components of your regular expression, please refer to the Java Documentation.
Letting Users Configure Their Passwords by Themselves
Maybe, some users should be able to set their password themselves. If you check the box User is allowed to change password, they can do so by selecting User 
>> Change user data... and entering a new password there.
Password Expiry
User passwords may be configured to expire after a certain amount of days. The configuration setting sophora.authenticate.changePasswordAfterDays specifies the duration in days, after which users are required to change their password. This setting applies to all users in your system. You can prevent the password of a specific user from expiring by checking Periodic password change is not required in the specific user document. In that case, the password will not expire even if it is unchanged for more than the number of days in the configuration setting.
You can also force a user to change his password by checking User is required to change password upon next login. If the user logs in the next time, he has to change his password before doing anything else. This works even if the user usually is not allowed to change his password by himself. This function could be useful if you discovered that your system has been compromised and all users should change their password.
Password Lost
To enable the "password lost" function for users, the following settings must be done in the sophora.properties file of the server:
| Property | Description | Example |
|---|---|---|
| sophora.mail.smtp.host | The host name of the SMTP server that is used to send mail. | mail.example.com |
| sophora.mail.sender.email | The e-mail address that is used to send mail by the Sophora server. | sophora@example.com |
| sophora.mail.sender.name | The name that is used as the real name to send mail by the Sophora server. | Sophora |
| passwordLost.mail.subject | The subject of mails that are sent to users containing the code for the "password lost" function. This can be set in the configuration document in the administration section, too. | Your Sophora account password |
| passwordLost.mail.text | The text of mails that are sent to users containing the code for the "password lost" function. ${code} inserts the actual code. \n inserts a line break. This can be set in the configuration document in the administration section, too. | Enter the following code to set a new password:\n\n${code} |
Reset Login (Requires Server 4.1.5 and DeskClient 4.2.3)
With the "Generate new password and send by e-mail" button in the user editor, administrators can generate a new password for the user.
The password is automatically sent to the user's e-mail address and the "force password change" checkbox is set.
To enable the feature for administrators, the "Reset Login" clientscript must be published and the following settings must be done in the sophora.properties file of the Sophora Server:
| Property | Description | Example |
|---|---|---|
| sophora.mail.smtp.host | The host name of the SMTP server that is used to send mail. | mail.example.com |
| sophora.mail.sender.email | The e-mail address that is used to send mail by the Sophora server. | sophora@example.com |
| sophora.mail.sender.name | The name that is used as the real name to send mail by the Sophora server. | Sophora |
| resetLogin.mail.subject | The subject of mails that are sent to users containing the generated new password. This can be set in the configuration document in the administration section, too. | Your Sophora account password |
| resetLogin.mail.text | The text of mails that are sent to users containing the generated password. ${username} inserts the username. ${password} inserts the actual password. \n inserts a line break. This can be set in the configuration document in the administration section, too. Both placeholders are required for this feature to work. | This is your new password:\n\n${password} |
Incorrect Logins
By default, users are able to try to login into the DeskClient unlimited times, even if they enter a wrong password. The number of invalid logins can be limited in the sophora.properties file of the Sophora server. The parameter sophora.authenticate.checkForIncorrectLogins determines whether the server checks for invalid logins (if a user enters his password incorrectly several times) and locks the account after a number of failed login attempts. By default, this check is disabled. The parameter sophora.authenticate.incorrectLoginCount declares how many times a user may enter a wrong password before his account is locked. The default value is 3 times.
The counter can be reset to '0' by the operation 'Login-Fehlversuche zurücksetzen' in the editor toolbar.
Account Expiry
User accounts may be configured to expire after a certain time of inactivity. The configuration setting sophora.authenticate.expireAfterDays specifies the duration in days after which a user account expires if the user has not logged in into the Sophora server during that time.
Additionally, a user account may be prevented from expiring by ticking the checkbox Deactivate 'locking due to inactivity' in that account.
User accounts that have administrator rights will never expire, regardless of configuration.
To unlock an expired account, set the account's last login date to the current date in that account's editor.
An additional help text that will be displayed in the error dialog when the user tries to log in can be configured using the sophora.authenticate.expireAfterDays.help configuration setting.
Staging User
There is the possibility to replicate a user to the Staging Servers. This requires the checkbox User is available on Staging Servers to be activated. Users will be stored on the Staging Servers without the personal data.
Please note that only a few selected users should be replicated to Staging Servers. These users gain all permissions on Staging Servers.
If there already is a user with the given username on the Staging Server and this user has not set the flag User is available on Staging Servers, the user will not be deleted on the Staging Server. This allows to create local users on the Staging Server or to grant other passwords.
Search user
This editor is accessible from the admin view via double-click on User Management >> Users (or its context menu entry Open).
Users can be searched by their properties as Full name, Phone or by roles like guest. There are also other filter mechanisms which you can see in the following illustration. The search result is shown in a table, where you can open the user document by double clicking the search result. Multi selections are also possible. The context menu (right click on at least one user) contains operations for editing and exporting one or more users at once.
You have different options available in the context menu, which are:
- Edit single: Open each of the selected users in a separate user editor.
- Edit selection: Open the form Edit users for editing all of the selected users at once.
- Edit search result: Open the form Edit users for editing all of the users from the search result at once.
- Export selection: Open an export wizard for exporting the selected users as a single Sophora-XML.
- Export search result: Open an export wizard for exporting all users from the search result as a single Sophora-XML.
- Delete selected...: Delete the selected users.
- Open user settings: Open the document which stores the settings of the user.
- Remove user setting...: Allows to select a key which will be removed together with its value from the stored settings. The user should not be logged in as else she might recreate the value from the current session.
