Session expired while saving a timesheet
Article ID: 76395
Updated On:
Products
CLARITY PPM FOR ITG
CLARITY PPM FEDERAL
Clarity PPM SaaS - Application
Clarity PPM On Premise
Issue/Introduction
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."
Cause
We are 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.
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.
Environment
CA PPM 15.2+ OP and OD
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.
Feedback
Powered by
