INC-145694 · Issue 601295
Property check handling updated for Ajax requestor
Resolved in Pega Version 8.2.8
SECU0001 alerts were seen when submitting a case in the interaction portal. Logging indicated the errors were related to the 'pxRequestor.pyLatitude' and 'pxRequestor.pyLongitude' properties which are included in an Ajax request when they exist in the DOM and the 'pyGeolocationTrackingIsEnabled' when rule is true. The error was traced to a condition where a new thread request results in an unexpected property check that encounters a clipboard which doesn't have any pages created for that thread. To resolve this, the 'pxRequestor.pyLatitude' and 'pxRequestor.pyLongitude' properties have been added to an allow list to handle the unexpected properties check.
INC-142648 · Issue 594805
PRTraceServlet security check added
Resolved in Pega Version 8.2.8
Modifying the Pega application URL with PRTraceServlet displayed multiple user credentials and session information. This has been corrected with the addition of a privilege check in GetConnectionListCommand before allowing the connections list to be fetched.
INC-155276 · Issue 622816
Null check added for step page
Resolved in Pega Version 8.3.6
After creating and adding new Access Roles and application 'Access When' to the privileges instead of Production level, during run time the error "runtime.IndeterminateConditionalException: Trying to evaluate Rule-Access-When conditions L:IsProdAccess when there is no page to evaluate them against" appeared for the specific privileges. This was traced to a missed use case where the system falls back to the step page if the page for evaluating the 'when' condition is null, which did not account for scenarios where the step page can be null. To resolve this, a null check has been added which will fetch the primary page if the step page for the access 'when' condition is null.
INC-156647 · Issue 626293
Improved disconnected requestor cleanup for FieldService
Resolved in Pega Version 8.3.6
A large number of requestors from FieldService with the status as 'Disconnected' were accumulating and causing performance issues. This was traced to the requestors not getting passivated due to users not logging out and new requestors being created for the same users next time, and was caused by the value of the DSS Initialization/PersistRequestor being set as "OnTimeout". When the DSS prconfig/timeout/browser/default is not configured, the default browser requestor timeout is 60 minutes. In this scenario, requestors were not passivating as the requestor passivation timeout was set to the refresh token lifetime for mobile users, which was very large and overwrote the DSS value. This has been resolved by removing the code which set the passivation timeout to the OAuth2 refresh token lifetime.