Session expired while saving a timesheet

book

Article ID: 76395

calendar_today

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.

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.