While every request that is sent from the client to the Application Server is always checked for authorization on the Application Server, the Smart Client still queries if the currently logged in user has a specific permission on a specific permission object in order to adapt its user interface. For example an item in a context menu could be disabled if the Smart Client knows that the Application Server request that would result from selecting this item will fail due to missing permissions.

Querying permissions many times before building up parts of the user interface influences the reactivity of the system, therefore the Smart Client uses an internal permission cache. Whenever the Smart Client queries a permission from the Application Server it will store the results of this query in its internal cache. The next time the Smart Client is querying for the same permission he will already get the result from its own cache.

The Smart Client's permission cache is not persisted, i.e. the permission cache will be empty on every start of the Smart Client.

Of course this permission cache on the Smart Client will have wrong information as soon as an already cached permission is changed on the Application Server. This can have two effects:

•Parts of the user interface are disabled even though the user was granted the permission to access the Application Server service after the permission was first queried by the Smart Client

•Parts of the user interface are enabled even though the user's permission to access the Application Server service was removed after the permission was first queried by the Smart Client

When you changing permissions on the Application Server (grant or delete privileges) it might therefore be necessary to restart the Smart Client. Alternatively you can select Clear client side permission cache in the Backstage Menu's Smart Client Administration tab.

Figure 1: Clearing the client side permission cache from the Backstage menu