Page History

Security

Settings

This section describe the settings related to Security module.Listar propriedades

Anchor
SecurityUserProperties SecurityUserProperties

Users

Pre-defined users

The following user names are configured by default:

• Administrator: built-in user that controls the Security System. No password is configured by default. You should set a password for this user.

• Guest: used by default to access and when you log off as another user. No password is configured by default.

• User: used as a generic login user. No password is configured by default.

The Guest user is the default user for anonymous logins and does not have a password assigned. It cannot be deleted or have a password added. When you log off as another user, the Guest user must be available. To restrict access to resources, you may modify the permissions for the Guest user.

Avoid creating other users with the same names or altering the row IDs of these built-in platform objects. The Administrator is the sole user capable of deleting, blocking users, and defining passwords for database interfaces.

Default properties

Anchor
SecurityPermissionsProperties SecurityPermissionsProperties

Permissions

Pre-defined Security groups

The platform comes with a few predefined Permission groups that you can use, or you can create your own.

• Administrator
• Guest
• User
• Engineering
• Supervisor
• Maintenance
• Operator

Edit permissions

Run permissions

Anchor
SecurityPoliciesProperties SecurityPoliciesProperties

Policies

Pre-defined Policies

The platform comes with a few predefined policies that you can use, or you can create your own.

• Default

• Enhanced

• Critical

Identification properties

Esign properties

Session properties

RuntimeUsers

Content

Advanced settings

Runtime Execution

Content about Security Runtime Execution

Anchor
MonitoringClientConnections MonitoringClientConnections

Monitoring Client Connections

The Monitoring Client Connections empowers you to track and manage active connections. This functionality enables efficient troubleshooting and resource allocation for your project's needs.

Anchor
ManagingUsersWithScripts ManagingUsersWithScripts

Managing Users with scripts

During the launch of an application, the Login process accepts all users defined in the Project Configuration. Additionally, it is possible to dynamically add Runtime Users during runtime execution, and they are stored in a default database located in Datasets → Dos → RuntimeUsers. Customization of the database used for user storage is also possible in the Module Datasets. Furthermore, users can be created or modified using the Security Namespace's available methods. 

To simplify user management, a platform Plugin is available in the Security Module that provides a template application for creating a Runtime Display. The UserManagement Plugin can be imported by selecting the appropriate Plugin in Project → Plugins. Once imported, the Plugin creates names, such as SecurityAccounts and ChangePass, that aid in user management.

The Security Namespace offers a wide range of methods that can be used to create or modify Runtime Users before starting runtime execution or during project execution. The documentation provides detailed information on the available features and methods, allowing users to enhance their application's functionality and flexibility during runtime. By utilizing the Security Module's capabilities, users can effectively manage Runtime Users, increasing the overall security and functionality of their applications.

In the following, you can find more details regarding the available RuntimeUser methods in the Security namespace:

Adding Runtime Users
@Security.NewRuntimeUser(string name, out int errorCode)
// Creates a new RuntimeUser
//  name:  User  Name
// errorCode: Error code (output)
// Returns: String containing the error message (if error) or empty (if not error)
 
@Security.AddRuntimeUser(string name, string permissionsStr, string password, string passwordHint, string policyStr, string profilePhone, string profileCompleteName, bool oneTimePassword)
// Add Runtime User
// name:  User  Name
// permissions Str: Permissions
// password: Password
// passwordHint: Password hint
// policyStr: Policy
// profileEmail: Profile email
// profilePhone: Profile phone
// profileCompleteName: Profile complete name
// oneTimePassword: flag (true or false) to set a One Time Password setting. If true, a password change is required after first login
// Returns: String containing error message (if error) or empty (if not error)

Anchor
CustomizingLoginProcedures CustomizingLoginProcedures

Customizing Login Procedures

The Login page is editable. You just need to select the display with name LogOn to edit its layout. As you can see in the code behind of that display, it calls the method Security.Logon() to do the validation of the user. If you want to perform any other user validation, you just need to modify that logic calling your own validation system, and then calling the LogOn method, according to the results of your validation.

Another way to customize the logon is to put your own custom logic on the ClientStartup script task. The script is executed on any computer that is connected to the server application. You can perform verifications based on computer IP, computer name, Windows Active-Directory Logged user, or any other criteria to specify if the user is allowed to start the application and which should be their credentials. After that, you can either call client.Shutdown to terminate the application if it was an unauthorized access or Security.Logon() with a user that matches the selected security profile.

By default, when starting the application on a client computer, instead of requesting a login, we start the system with the user GUEST. The user Guest is equivalent to an anonymous login. If you do not want that on your application, just replace the startup page with a page requesting the Logon information.

In this section...