Session expired while saving a timesheet

Document ID : KB000076395
Last Modified Date : 12/06/2018
Show Technical Document Details
Issue:
One of our resources is trying to edit/update his time sheet in the Classic UI. He is getting an expired session error message every time. There are dozens of tasks on the timesheet after we hit "Populate All."
Environment:
CA PPM 15.2+ OP and OD
Cause:
The problem that BMO has in getting the CSRF error when saving a timesheet is due to the timesheet being so large.

There is a limit that Tomcat has on the number of parameters it will allow on a GET + POST.

This is from the Tomcat documentation:
maxParameterCount

The maximum number of parameter and value pairs (GET plus POST) which will be automatically parsed by the container. Parameter and value pairs beyond this limit will be ignored. A value of less than 0 means no limit. If not specified, a default of 10000 is used. Note thatFailedRequestFilter filter can be used to reject requests that hit the limit.

We don't set this in the on-demand service so the default of 10000 is in play.

The maxParameterCount is not something we want to disable. It is there to provide some level of Denial-Of-Sevice attack protection. The form for this particular timesheet is just too big for Tomcat to handle. It is the way the Classic timesheet has been designed, i.e., to submit the entire timesheet as a form.
Resolution:
The suggestion here is that the timesheet needs to be pruned of irrelevant time entries prior to submission. 
Additional Information:
The new UX Timesheet does not have this problem as only updates to the cells are sent as they occur so the entire form is NEVER posted in one shot.