CA has introduced a new, configurable set of CSRF strategies for Clarity 13.2. The allowed configurations are:
• none - no CSRF token is generated nor is any request validated. This is the default setting for on-premise installations. Recommended if Clarity is behind your corporate firewall. Upgrading customers will have this setting automatically.
• request - This implements the same strategy used in Clarity 13.1. This strategy generates a new token for each request and validates against a limited size cache in the user session. Due to the possibility of cache exhaustion, this strategy can lead to false-positive validation errors, especially for users who work with multiple tabs open in Clarity.
• session - a single token is generated for the user session and that is used for validation. This is the recommended strategy for on-demand SaaS and hosted installations; and for on-premise customer installations where Clarity is outside the corporate firewall.
Configuration is done by manually setting an attribute of the applicationServer element in the properties.xml file:
1. Stop the app and bg services on your application server
2. Open the properties.xml file for editing
3. Use this sample as an example of where to edit the setting:
<applicationServer vendor="tomcat" useLdap="false" home="c:\ca\tomcats\apache-tomcat-7.0.26" adminPassword="secret" externalUrl="" tokenCacheStrategy="session">
<applicationServerInstance id="app" .../>
<applicationServerInstance id="nsa" .../>
4. Restart the app and bg services
5. Synchronize the properties.xml file changes across all applications servers if Clarity is running in a clustered environment
Upgrading To Clarity 13.2: The tokenCacheStrategy setting is automatically set to none. No further action is required.
Clarity PPM 12.1.3:
1. Check the app-niku.log
2. Look for the message 'The request could not be completed due to a conflict with the current state of the resource'. The message will also specify the action id for which the security check has failed.
ERROR 2013-03-08 11:38:24,560 [http-80-7] web.WebActionController (admin: 5016871__4AEAF7D8-F49A-4FA1-863B-2E97ADC3BDC9:npt.myDashboardsFilter) com.niku.union.web.WebException: The request could not be completed due to a conflict with the current state of the resource
From the example log, the action that caused the issue is npt.myDashboardsFilter.
If the message 'The request could not be completed due to a conflict with the current state of the resource' is not found in the log, contact CA Support. This may be an application error and not a CSRF error.
3. Locate the CMN_OPTION_EXEMPTED_ACTION_VALUES.xml file delivered as part of the 12.1.3 patch. Continue to Step 4 below, in the section for 12.1.3, 13.0, 13.1 Versions
Clarity PPM 13.0 and 13.1:
1. The CSRF Security Violation error page in the application contains the Request ID of the failing action.
2. If the error page is no longer available for your reference, follow Steps 1 and 2 in the Clarity PPM 12.1.3 section, checking the app-ca.log.
3. Contact CA Support and ask for the CMN_OPTION_EXEMPTED_ACTION_VALUES.xml file
12.1.3, 13.0, 13.1 Versions:
4. Copy the file CMN_OPTION_EXEMPTED_ACTION_VALUES.xml from TEC567263.zip file to the following location:
5. Open the CMN_OPTION_EXEMPTED_ACTION_VALUES.xml for editing
6. Look for the variable actions_list (comma separated)
ORACLE: actions_list varchar(2000) := 'Enter actions here';
MSSQL: SET @actions_list = 'Enter actions here'
7. In actions_list variable, add the Request ID for the action(s) that caused the exception. If there is more than one action, separate the IDs by commas. Please ensure that there are no spaces. If there is only one action, then do not add comma. Save the file.
8. Execute the dbpatch command to apply the changes:
$CLARITY_HOME\bin>dbpatch -install -file $CLARITY_HOME\database\schema\
9. Ask the end user to clear their browser caches. They should not see an exception for the same action.