Skip to main content

Resolved Issues

View the resolved issues for a specific Platform release.

Go to download resolved issues by patch release.

Browse release notes for a selected Pega Version.

NOTE: Enter just the Case ID number (SR or INC) in order to find the associated Support Request.

Please note: beginning with the Pega Platform 8.7.4 Patch, the Resolved Issues have moved to the Support Center.

INC-164432 · Issue 696294

Global obfuscation key initialized on first requestor call

Resolved in Pega Version 8.6.4

When using URLEncryption = true and SubmitObfuscatedURL = optional, attempting to export an Excel spreadsheet resulted in the error "Invalid character found in the request target". This was traced to the variable pega.d.globalobfuscateKey having a null value which was then converted to a byte array and decoded, generating improper characters in the URL. After a browser refresh, the correct value was set in pega.d.globalobfuscateKey and the export worked as expected. To resolve this, an update has been made to initialize the key on the very first call in PRRequestorImpl when the global obfuscation key is determined to be NULL instead of initializing the global obfuscation key by on-demand basis from HTTPAPI.

INC-182827 · Issue 691528

URL security updated

Resolved in Pega Version 8.6.4

Security has been updated for URL tampering defense and Rule Security Mode.

INC-209298 · Issue 704141

Added security tokens to Worklist assignment error wizard

Resolved in Pega Version 8.6.4

After enabling CSRF, moving to 'Configure -> Case Management -> Tools -> Work Admin -> Worklist assignment errors' and then selecting a record and clicking on 'Delete' resulted in a '403 Forbidden' error. This has been resolved by adding CSRF and fingerprint tokens as part of the form data.

INC-211426 · Issue 706061

UI and code changes to support Client Assertion in Open ID Connect

Resolved in Pega Version 8.6.4

In order to support private_key_jwt, an enhancement has been added which will pass the “Client ID” and “Client assertion” (in the form of a signed JWT) as part of the authorization code grant flow for an IDP-initiated SSO. The Authorization Server will then authenticate Pega (the client) to verify the signature and payload of assertion by retrieving the public key via Pega’s JWKS endpoint.

INC-215343 · Issue 711141

Security updates

Resolved in Pega Version 8.6.4

Security updates have been made relating to rulesets using allow lists, checks for Java code injections, SAML-based SSO code, and supporting SFTP as part of the validation in the pxValidateURL rule.

INC-134046 · Issue 575238

database locking improved for login performance

Resolved in Pega Version 8.5

A slowness issue seen when trying to login to my.pega.com was traced to numerous database locks occurring on the pr_data_saml_authreqcontext table during the SAML flow. Analysis showed that while running Obj-Save on AuthRequestContext with 'OnlyIfNew' as false, the check caused a select query to run on the table to determine if the context was already there and insert it if it was not. To resolve this, the onlyIfNew check will default to true to avoid running the query; if the context is already present it will be overridden. Duplicate key exception handling has also been added to avoid any issues if a resave is done with same key.

SR-D96395 · Issue 555118

CDK key loading modified for better database compatibility

Resolved in Pega Version 8.5

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).

INC-132209 · Issue 577000

CDK key loading modified for better database compatibility

Resolved in Pega Version 8.5

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).

INC-118927 · Issue 571491

Resolved OAuth2 mobile app loop

Resolved in Pega Version 8.5

When a Pega OAuth2 authorize endpoint was invoked and the redirect URI contained "app", a loop was created where the system attempted to fetch the app alias from the state parameter value and was redirected back to itself. This could sometimes result in inconsistent mobile app styling. Investigation showed that a certificate with keyword app that was picked for the redirect URI could have the key word assumed to be the app alias context, so a workaround was to remove the app keyword. To resolve the issue, the system has been updated to look for the app alias only in the state parameter rather than performa a string contains check on the entire query string.

SR-D79181 · Issue 551124

OKTA receives parameters on logout

Resolved in Pega Version 8.5

When using an OIDC logout endpoint with a parameter set as a data page value, the data page retrieved the ID Token from the database, but when logout was clicked the datapage name was being displayed in the browser instead of the IDToken. To resolve this, code has been added to support sending ID token parameters for logoff endpoint for OKTA logoff using OpeniD connect.

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us