You can use this data to tailor the GUI components displayed at the client. An example would be to display information that the user is allowed to view, and to hide information that the user is not allowed to view. This information could be anything from pricing data for currency pairs, to menu items, data grids, trade tiles, and tenors.
Security
User permissioning and authentication is enforced by the Permissioning Auth Module at the Liberator server. It is not possible to modify these product permissions from Caplin Trader. The classes in this package only allow you to query the permissions that have been assigned to the currently logged in user; they do not allow you to change these permissions.
More about Permissioning at the client
When a user logs in to Caplin Trader, the application automatically subscribes to the permissioning data that Liberator holds for that user. At the start of the subscription Liberator sends Caplin Trader all the permissioning data for that user, followed by subscription updates whenever a product permission changes.
The classes in this package provide an interface to this permissioning data, allowing you to tailor your copy of Caplin Trader to match the permissions of the currently logged in user.
Since Caplin Trader automatically subscribes to permissioning data, the latency of each permissioning query is reduced. This is because Caplin Trader holds a local copy of the latest product permissions, and does not need to contact Liberator each time your code initiates a query.
Product Permissions
Product permissions are sent to Liberator by the Permissioning DataSource. A user can have any number of product permissions assigned to them, where each permission determines whether an action on a product will be allowed or denied.
Permissions for actions can reside in either the global (default) namespace or a specific namespace. Permissions are typically defined in a specific namespace to group related actions. An example would be to group tenor permissions by defining these permissions in a "tenor" namespace. Your client application could then query the tenor namespace to determine the tenors that are allowed and those that are denied.
The table below shows four such permissions, where each row of the table defines a single product permission. Note that the final column of the table (Significance) is not part of the permission, and is only included here to provide a description of the permission.
| Namespace | Product | Action | Authorization | Significance |
|---|---|---|---|---|
| null | .* | VIEW | ALLOW | Allow the user to view all products. |
| null | /FX/.* | TRADE | ALLOW | Allow the user to trade all FX products. |
| tenor | /FX/.* | 1_WEEK | ALLOW | Allow the user 1-week tenor for FX products. |
| tenor | /FX/.* | 2_WEEK | DENY | Deny the user 2-week tenor for FX products. |
You will see from the table above that JavaScript regular expressions have been used to define the product. In this way the same permission can be applied to a range of products. When a user attempts to view or trade a product, Liberator consults pre-defined permissioning rules that indicate the permissions that the user must have in order to complete the task.
The permissions in the first two rows of the table above allow the user to view all products, and to trade any FX product. In this case the namespace is null, which indicates that the permission resides in the global (default) namespace. This type of permission would typically be used at the client to enable or disable the display of products or product grids.
The permissions in the last two rows of the table are defined in the "tenor" namespace. These permissions allow the user to trade any FX product with a 1-week tenor, but do not allow the user to trade any FX product with a 2-week tenor. These permissions would typically be used at the client to:
- Enable the 1-week tenor option.
- Disable (or hide) the 2-week tenor option.