SR-B42009 · Issue 304044
Authentication timeout smoothed for re-login
Resolved in Pega Version 7.3
If custom authentication was used with a stream specified to enter credentials upon authentication timeout, re-login failed after the timeout. This was traced to two issues: first, the custom configuration defaulted to using the out-of-the-box stream "Web-TimeOut", which expects the password to be in base64 encoded format and so attempts to base64 decode it. This caused an authentication failure. Second, when restarting with authentication instead of a timed-out request, the starting activity of operator was being executed and the portal was rendered unexpectedly. To resolve this, the object references needed for the successful resumption will be cloned when there is authentication timeout and used for redirection upon successful authentication.
SR-B43182 · Issue 301518
pzSUS Param properly URLEncoded
Resolved in Pega Version 7.3
The Tomcat 8+ server was rejecting DWA URLs due to characters such as {,} that it considered to be unsafe. These characters were introduced by pzSus key in the URL, and these values will now be encoded for the browser to resolve these issues.
SR-B44199 · Issue 300058
Fixed Access Control Policy in Assign- classes
Resolved in Pega Version 7.3
An error was generated when attempting to create an Access Control Policy in Assign- classes. This was due to a missing use-case, and has been corrected.
SR-B44199 · Issue 299984
Fixed Access Control Policy in Assign- classes
Resolved in Pega Version 7.3
An error was generated when attempting to create an Access Control Policy in Assign- classes. This was due to a missing use-case, and has been corrected.
SR-B44199 · Issue 297134
Fixed Access Control Policy in Assign- classes
Resolved in Pega Version 7.3
An error was generated when attempting to create an Access Control Policy in Assign- classes. This was due to a missing use-case, and has been corrected.
SR-B6669 · Issue 279329
XSS filters added to UI rulesets
Resolved in Pega Version 7.3
XSS filters have been added to pyCaseActionArea and pyAssignmentsLabel in Pega-EndUserUI and UIKit rulesets.
SR-D23239 · Issue 499595
Support added for multi-operator SAML logins
Resolved in Pega Version 8.3.1
When a SAML user is logged in by Single Sign-On (SAML), the system processes the login to portal as a different operator if there was a function on the Attribute field under Operator identification in the SAML authentication service. In this scenario, using an expression for operator provisioning did not work because all SAML login sessions resolved to the same first operator due to parseAndEvaluateExpression() in ExpressionHelper.java ignoring new expression arguments if the expression page already existed. To support the use of multiple operator logins in this format, the system has been updated to clone a new expression page for every session and update it with the correct expression arguments.
SR-D47611 · Issue 513113
HTTPS login path issue resolved
Resolved in Pega Version 8.3.1
When using iOS, entering wrong credentials for a login with an https endpoint converted the URL to http. This was traced to a case where the resourcePath was coming as http in SSL enabled system, but the reqURI was still https. To correct this, the system has been updated so that if the reqContextURI starts with https and the requestURL starts with http, then the requestURL will be converted to https.
INC-118838 · Issue 560691
OKTA receives parameters on logout
Resolved in Pega Version 8.2.7
When using an OIDC logout endpoint with a parameter set as a data page value, the data page retrieved the ID Token from the DB, 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.
SR-D95148 · Issue 557483
Port validation updated for redirect URI
Resolved in Pega Version 8.2.7
When an offline app for windows client was generated, trying to login via SSO resulted in the error "invalid redirect_uri". This was traced to the system validating the whole loopback redirection URL, e.g. "http://127.0.0.1:1234/redirection", including the port number. To enhance flexibility, an update has been made so that the port number will not be validated, allowing the client to establish it based on availability at the moment of the request to the authorization service. NOTE: As a best practice, a loopback URL should not be configured as a redirect URI. If a loopback URL is configured, then at run time the port number will not be validated, and the client application can use any available port on the system including ports that may not be intended for use.