SR-B93934 · Issue 340753
Sensitive handling added for validation of encrypted SOAP
Resolved in Pega Version 7.4
The WSS4J library was not calculating the processing actions validation on encrypted SOAP messages correctly after the message's security requirements were already processed by the library. This means that the verification of signature or decryption or any other actions worked and the necessary security processors were engaged correctly, however the check was failing during the last leg of the processing actions validation. Since the action matching is of less significance, the validation for actions will be relaxed in situations where the ws-security config is signature and encryption and/or timestamp.
SR-B95798 · Issue 344526
XSS filtering added to GetTour
Resolved in Pega Version 7.4
Cross scripting filtering has been added to pxGetTour java step 7, which prepares JSON.
SR-C1107 · Issue 351146
Oauth tokens obtained on login timeout
Resolved in Pega Version 7.4
When the client idle time expires, the user must perform a login in order to get back into the application. If OAuth is being used for authentication there is no need to re-send the credentials to NetIQ if neither the refresh token nor access token are expired yet, but the hybrid client was repeating the ROPC flow and obtaining a new refresh token each time the user logged in after the client idle timeout expires. With this change, the tokens are obtained on login timeout. There will be a further update targeted for the next release to show the lock screen and not log the user out.
SR-C1107 · Issue 351606
Oauth tokens obtained on login timeout
Resolved in Pega Version 7.4
When the client idle time expires, the user must perform a login in order to get back into the application. If OAuth is being used for authentication there is no need to re-send the credentials to NetIQ if neither the refresh token nor access token are expired yet, but the hybrid client was repeating the ROPC flow and obtaining a new refresh token each time the user logged in after the client idle timeout expires. With this change, the tokens are obtained on login timeout. There will be a further update targeted for the next release to show the lock screen and not log the user out.
SR-C147 · Issue 343884
Security improvements for generateCellContent RUF
Resolved in Pega Version 7.4
Code changes have been made to improve security for getting the parameter value in the generateCellContent RUF.
SR-C1787 · Issue 346038
XSS filtering added for insHandle
Resolved in Pega Version 7.4
XSS filtering has been added for the inshandle parameter in the downloadFile activity.
SR-C1787 · Issue 320158
Exception message will not include invalid filename
Resolved in Pega Version 7.4
To enhance security, the exception message In the activity Rule-File-Binary.downloadFile will not display the invalid filename.
INC-203994 · Issue 698853
DSS added to handle merges with lower versions of Postgres
Resolved in Pega Version 8.7.1
After update, executing the batch campaign with volume constraint resulted in the second data flow DF_Wait failing with error message "ERROR: number of columns (1844) exceeds limit (1664)". This was due to the database set’s change (in 8.5) to use the database layer’s merge statement. Prior to that, the logic used "deletes and inserts". Depending on the version of Postsgres, the generated SQL statement for a merge statement is different. The “INSERT … ON CONFLICT … UPDATE” syntax is generated for Postgres 9.5+ AND when there is a PK constraint defined for the DB table. Otherwise, the complex UPSERT statement (old syntax) is generated, as was the case in this issue. This is a known issue in the Postgres server software where it mis-interprets the number of columns involved. i.e., it mistakenly counts the number of columns twice. As a result, the actual maximum columns allowed is only half of the official limit (1664). The same UPSERT statement does not cause the “exceeds limit” exception if there are 832 or fewer columns in the statement. To resolve this, an option has been provided to select between the “original logic” (deletes and inserts) and the “merge statements” logic by way of the DSS “decision/datasets/db/useMergeStatementForUpdates”. Setting “true” will use the merge statement logic, and setting “false” will use deletes and inserts. When the DSS is not defined, the default is "true" and the system will use merge statements in the form preferred by Postgres 9.5+.
INC-180246 · Issue 699700
Support for apostrophe added to keyword tokenization
Resolved in Pega Version 8.7.1
A keyword containing an apostrophe was not detected properly in Text extraction model. This has been resolved by updating the annotator used in the tokenization.
INC-193399 · Issue 688115
DSS added to handle merges with lower versions of Postgres
Resolved in Pega Version 8.7.1
After update, executing the batch campaign with volume constraint resulted in the second data flow DF_Wait failing with error message "ERROR: number of columns (1844) exceeds limit (1664)". This was due to the database set’s change (in 8.5) to use the database layer’s merge statement. Prior to that, the logic used "deletes and inserts". Depending on the version of Postsgres, the generated SQL statement for a merge statement is different. The “INSERT … ON CONFLICT … UPDATE” syntax is generated for Postgres 9.5+ AND when there is a PK constraint defined for the DB table. Otherwise, the complex UPSERT statement (old syntax) is generated, as was the case in this issue. This is a known issue in the Postgres server software where it mis-interprets the number of columns involved. i.e., it mistakenly counts the number of columns twice. As a result, the actual maximum columns allowed is only half of the official limit (1664). The same UPSERT statement does not cause the “exceeds limit” exception if there are 832 or fewer columns in the statement. To resolve this, an option has been provided to select between the “original logic” (deletes and inserts) and the “merge statements” logic by way of the DSS “decision/datasets/db/useMergeStatementForUpdates”. Setting “true” will use the merge statement logic, and setting “false” will use deletes and inserts. When the DSS is not defined, the default is "true" and the system will use merge statements in the form preferred by Postgres 9.5+.