I am doing work in trying to santize the request and response DTO’s that are now being logged and that are also stored by the RequestLogsFeature.
It turns out that when an exception is thrown by the code (like an UnAuthorizedAccessException) the raw request DTO is included in the StackTrace of the response (in DebugMode).
Since the RequestLogsFeature stores multiple requests, and they are stored for review later, we simply cannot have secrets (eg. passwords) in plain view. For operational security (whether Debug or not).
I have been working on sanitising the result that comes back from DtoUtils.CreateResponseStatus() in our custom appHost.ServiceExceptionHandler filter, but if I return a sanitised responseStatus from that filter, no exception is thrown. If I return null from that filter, then the response remains unsanitised (since our code is not used). Ideally, I would return our sanitised version and throw an exception. But that seems like not the way to proceed.
Is there another hook I need could look at to ensure that these raw request DTOs do not reach the RequestLogs output (or any other place such as log files, where this stuff could be written in the framework? - not confident I could reliably enumerate all of those possibilities)
Ideally I would be providing my own `DtoUtils.CreateResponseStatus()’ method, but it is used all over the place.
This approach solves the problem with raising an exception. Which is cool. new HttpError(responseStatus, statusCode, responseStatus.ErrorCode, responseStatus.Message, exception.InnerException);
However, now the actual values of the thrown WebServiceException (that is raised through SS client) is dramatically different, than it used to be when I returned null from the ServiceExceptionHandlers filter
For example: WebServiceException.ErrorMessage was: “a thrown exception message”, is now: “null” WebServiceException.Message was: “a thrown exception message”, is now: “AThrownExceptionTypeName” WebServiceException.ServerStackTrace had a value, is now: “null”
Clearly the mapping to WebServiceException is now quite different, but I’m not sure where to go now to change that back
It’s hard to tell without the ability to reproduce and know what you had vs what you are filtering.
Have a step through the HandleExceptionAsync. When returning null from your custom ServiceExceptionHandler, this should fallback to DtoUtils.CreateErrorResponse which you should be able to replicate from your service exception, with the sensitive data removed.
Those WebServiceException properties being null sounds like a ResponseStatus maybe resulting differently.
Before I made any changes we were returning null from our custom ServiceExceptionHandlers, AND then we were seeing the values I was stating from a WebServiceException in a SS client.
(Right or Wrong, I have many 10s of integration tests confirming that).
Doing what you suggested: returning new HttpError(responseStatus, statusCode, responseStatus.ErrorCode, responseStatus.Message, exception.InnerException); where responseStatus is essentially the result of a call to DtoUtils.CreateResponseStatus() is now altering the properties of WebServiceException
What I am looking for (and what is missing for me) is the code in the SS framework that translates a returned value of null from a ServiceExceptionHandler into something else.
But I don’t see, stepping through the debugger.
OK, so if you are telling me that null translates to a call to DtoUtils.CreateErrorResponse(), then let me figure out how to emulate that the way I need to.
