Thank you for your feedback.
Form temporarily unavailable. Please try again or contact to submit your comments.

Double-check form submission

Log in to subscribe to topics and get notified when content changes.

Additional security options

The application has a wide variety of security options to choose from.

Depending on the security requirements of your particular deployment, it might make sense to run the system with all of its security options enabled. Some of the options make the system more secure, but can offer additional complexity from an implementation standpoint.

All security settings in this page are configured in System Properties > Security.

Remember me login cookie

When you log on to the instance, you have the option to select the Remember me check box on the login screen, which stores a cookie on your browser.

This cookie contains information that the application server can use to authenticate your user credentials automatically the next time you visit the instance. For most users, this is a highly convenient feature.

In some deployments, however, it is desirable to have users authenticate with the system every time they connect. To support this, the system lets you disable the Remember me functionality by removing the corresponding check box (and its resultant cookie) from the login screen.

The default value for the Remember me check box can also be changed.

Property Property Default

Remove Remember me" check box from login page


Property disabled (Remember me check box is visible)

Default value of Remember me check box on login page

Property enabled (Remember me check box is selected)

You can also modify the session timeout, forcing users to reauthenticate if they do not continue interacting with the instance. Session timeout only works if the Remember me check box in the login screen is not selected.

Double-check form submission

When the system determines that a particular field (such as task.number) should not be written to by the current user, the system renders that field in a read-only mode, which is why the number field is not writable on most incidents.

If you set the system to double-check the values of any incoming fields for writability, then the system applies the same set of security rules to the inbound leg of a transaction. When you submit an incident, for example, the system double-checks to determine if the number field can be written to before posting any changes.

If you tell the system not to double-check inbound transactions, then the system allows you to write to a nominally read-only field if that is the transaction the client sends back. In many deployments this is actually a desirable behavior if, for example, you are using client scripts to set nominally read-only fields in response to user selections in other, writable fields.

Property Default

Double check security on inbound transactions during form submission (rights are always checked on form generation)

Disabled (no double checking)

Enable the AJAXEvaluate processor

As was mentioned in the section on script sandboxing, the AJAXEvaluate API call allows the client to send, and execute, arbitrary script on the server.

For an additional level of security, over and above that offered by the script sandbox, it is possible to entirely disable the AJAXEvaluate processor, in which case any API calls made to that processor are ignored.

Property Default

Enable the AJAXEvaluate processor.

Disabled (API is disabled)

Apply ACLs to AJAXGlideRecord (client-side Glide record)

From within client scripts, it is possible to query arbitrary data from the server via the AJAXGlideRecord (renamed GlideAjax) API, by using syntax similar to a server-side glide record. This is an extremely powerful and useful tool in many deployments. You can set a system property to perform ACL validation when server-side records (for example, tables) are accessed using GlideAjax APIs within a client script.

If you choose to apply access control lists (ACL) to GlideAjax API calls, then you can only query data to which the currently connected user has rights to access. For example, if the user is logged in as an ESS user who has no rights to read the cmn_location table, then any GlideAjax API call by the user will fail.

If you run the system without an ACL checking on GlideAjax calls, then the API can return information that the currently logged in user could not otherwise access via the UI.

Property Default

Apply standard security ACLs to AJAXGlideRecord calls

ACL checking enforced