INC-141940 · Issue 601543
Revoke Access Token check removed from OAuth Client Registration
Resolved in Pega Version 8.4.4
When client credentials were implemented, the OAuth 2.0 Client Registration form was designed such that once the instance was created and a token issued, the access tokens were deleted on save. Process changes now indicate that it should be possible to save the form because it may only have History Description/Usage changes made to it and Revoke Token and Regenerate Secret buttons are already available. To address this, the Revoke Access Token check has been removed from the validate activity of Client Registration.
INC-144591 · Issue 601611
Oauth and beanutils jars upgraded
Resolved in Pega Version 8.4.4
The third party Oauth2 jars and commons-beanutils jar have been updated to the latest versions.
INC-144597 · Issue 598307
Updated handling for MT query of pr_data_admin table
Resolved in Pega Version 8.4.4
When using a multi-tenant environment with Oracle, as the number of users in the environment increased, the number of queries of the pr_data_admin table "WHERE pyEnableAuthService" increased exponentially and causes system slowness. This was traced to missed handling for the @ character in the authentication service cache while requesting, and has been resolved by updating authservicecache.java.
INC-145033 · Issue 599482
ForgotPassword responses made consistent
Resolved in Pega Version 8.4.4
To prevent possible exposure of valid usernames, the ForgotPassword logic has been updated so that it will show the same messages and set of screens to both valid and invalid users if a lost password request is made.
INC-146434 · Issue 602740
Accessibility added to Security Event Configuration headers
Resolved in Pega Version 8.4.4
Labels for the headers in the Security Event Configuration screen have been converted to dynamic layout headers so they will be detected by JAWS screen reader.
INC-146921 · Issue 601638
Cross-site scripting update for Dev Studio
Resolved in Pega Version 8.4.4
Cross Site Scripting (XSS) protections have been added to Developer Studio.
INC-154627 · Issue 619570
Re-enabled users are able to log in
Resolved in Pega Version 8.4.4
When disabled operators were re-enabled through operator management, the forced password change on next login was manually unchecked but the operators were unable to login because the change password screen was displayed without any password entry fields. This was a missed use case for handling the change password flag on a requestor , and has been resolved by having the system skip setting the change password on next login flag for disabled users.
INC-166995 · Issue 642440
DeleteDocumentPg added to allow list
Resolved in Pega Version 8.7
During performance testing with CSRF settings enabled, a '403 Forbidden' error was seen in the network trace when FinishAssignment called pyActivity=pyDeleteDocument on close action. This has been resolved by adding pyDeleteDocumentPg to the list of allowed activities.
SR-D86011 · Issue 548152
Browser fingerprint validation issue resolved
Resolved in Pega Version 8.3.3
After upgrade, Pega logoff was happening automatically within five minutes while using Microsoft Internet Explorer. This was traced to the COSMOS-based portal in Microsoft Internet Explorer 11 generating different hashes for different parts of the screen, causing a "Browser fingerprint validation failed" error because of the pzBFP token mismatch. To resolve this, an update has been made to exclude the graphic components for calculation of browserfingerprint.
SR-D96395 · Issue 555117
CDK key loading modified for better database compatibility
Resolved in Pega Version 8.3.3
Users were unable to log on to the system and received the error "There has been an issue; please consult your system administrator." Investigation showed the log errors stating "(dataencryption.DataKeyProvider) ERROR localhost - Could not get CDK from systemKeyManagementCache - System CDK is null". This was an issue specific to the MS SQL Server database when there were 6 or more CDKs in the database: CDK keys are loaded from database into Cache using an SQL statement which had the ORDER clause. By default, the ORDER clause treats NULL values differently on different databases, and this caused MS SQL databases to not load a necessary CDK key. To resolve this, the SQL query has been modified so the result will be the same for all supported daatbases (Oracle, Postgres & MS SQL Server).