Client Security
Client Permissions
Every project's clients are governed by a set of permissions to control what is allowed to originate from the client. For example: access to construct queries against the database, or the ability to edit Users and Roles in your authentication profile. To maintain a secure system, these are all set to OFF by default but you can enable them for everyone, for specific users, or even for specific users that are logged into certain zones. See descriptions of these categories and how to change them on the Project Permissions page.
Unlike new Ignition projects, any projects that were created before 7.9.4 and then updated beyond 7.9.4 will have these permissions set to true.
Role-Driven Client Security
On the simplest level, security settings can be applied to individual windows or components. Users with different roles can all view the same project from the client, but the functionality and readability can change based on the roles assigned to each user. Generally, higher level access provides full functionality to all contents of a project, and lower level access is restricted to generalized read-only privileges. However, client security settings are flexible enough to accommodate any security requirements.
Below we see the Security Settings panel in action. This panel is the interface that applies Ignition's built-in security settings. Security settings can be applied to a single component, multiple components simultaneously, or even a whole window. Users who should be allowed full access can be selected, and restrictions can be applied for users that should not have full access.
Projects are assigned a User Source to authenticate against. All roles that have been defined in the User Source can be referenced in the client to block or allow access. Once roles have been created, you can easily start assigning component-specific security settings in the Designer.
More information can be found on the Component and Window Security page.
Incorporating Scripting into Security
The component-based security settings are fairly simplistic: the user either has the required roles, or a restriction applied. In situations where consideration for access should go beyond a simple role check, security-based scripting can provide a larger degree of granularity. Information about the logged-in user, such as user-name or roles, can be detected by scripting, allowing for the creation of a robust security system.
More information can be found on the Security in Scripting page.