I’m looking into a finding where a HTTP GET-request was done to the SSO URL of our Pega application, a database-exception was happening and this got returned in the HTTP response body showing all details like the INSERT-query and the values.
I’m not able to reproduce the issue but I would guess there’s a setting to surpress exceptions from coming back in the HTTP request.
The prconfig/initialization/DisplayExceptionTraceback/default DSS can be used to prevent the display of stack-trace when an error occurs. However, there is no explicit setting mentioned in the provided context that suppresses exception details from being returned in the HTTP response.
@MarijeSchillern Thanks for your answer and looking it up.The DSS prconfig/initialization/DisplayExceptionTraceback/default was already existent on all environments and set to false, on stg1 it was installed long time ago and pxCommitDateTime is 2022. So unfortunately it didn’t avoid the exception from coming back in the HTTP response.
The other DSS in the links like prconfig/alerts/database/operationTimeThreshold/suppressInserts/default suppress details for going into the alert log but don’t relate to HTTP response.
The DisplayExceptionTraceback DSS should do the job,
If this is not the case I would recommend creating a Support Incident, attaching the whole message returned back to the client, including the stacktrace of the exception and the message text (with any sensitive and PII data redacted please), so that the issue can be investigated more in depth.
An alternate solution, is to configure the Servlet Container to avoid returning detailed HTML error page.
For instance, in Tomcat this can be done by either configuring the Error Valve or by providing custom error pages in application web.xml deployment descriptor.
Please engage your sysAdmin to figure out the approach that is more suitable in your case.
