spring-projects / spring-integration

Spring Integration provides an extension of the Spring programming model to support the well-known Enterprise Integration Patterns (EIP)
http://projects.spring.io/spring-integration/
Apache License 2.0
1.54k stars 1.1k forks source link

Conditionally Display Message and Header in MessageHandlingException #9416

Open gc-1111 opened 3 weeks ago

gc-1111 commented 3 weeks ago

I would like to force spring integration not to display certain messages/headers, because they may contain PII.

Tell us how it should works If message header hideMessageDataInException=true

Exception Message should have no "FailedMessage" Section: org.springframework.messaging.MessageHandlingException: error occurred during processing message in 'MethodInvokingMessageProcessor' [org.springframework.integration.handler.MethodInvokingMessageProcessor@5494e631]

Note: hideMessageDataInException can default to false to maintain existing behavior.

Explain the difference from current behavior Currently, the exception always includes failedMessage section of error message. We have no way to block failedMessage from appearing, even if the message include PII. We would like to log the exception, but it has PII in it.

org.springframework.messaging.MessageHandlingException: error occurred during processing message in 'MethodInvokingMessageProcessor' [org.springframework.integration.handler.MethodInvokingMessageProcessor@5494e631], failedMessage=GenericMessage [payload=hasPII, headers={hasPII}]

How has this issue affected you? We are not able to hide PII in the logs.

What are you trying to accomplish? We would like to log our error message, but not include the failed message in the logs. I get why often it is nice to have the failedMessage in the logs, but there is no way to turn that off.

What other alternatives have you considered? We could make a custom logger, that check each logged string for failedMessage=GenericMessage... and remove that section of the log message.

Are you aware of any workarounds? Not really.

gc-1111 commented 3 weeks ago

For adding the header, I think something like this: .enrichHeaders(h -> h.header(MessageHeaders.HIDE_EXCEPTION_MESSAGE_DATA, "true") )

Then that would turn off the failedMessage= display in the exception.

gc-1111 commented 3 weeks ago

It's fine if you want to make it a setting or something. However, the idea is to condition hide failedMessage in the exception(s).

gc-1111 commented 3 weeks ago

This no PII in logs thing is a new security concern. I think it's getting more popular. I suspect a lot of companies have PII in the messages. It would convenient to avoid dumping it to the logs.

artembilan commented 3 weeks ago

It is hard to continue discussion on StackOverlfow: https://stackoverflow.com/questions/78898981/how-to-remove-pii-from-messagehandlingexception-in-spring-integration

Some more info and ideas are here: https://www.skyflow.com/post/how-to-keep-sensitive-data-out-of-your-logs-nine-best-practices.

Still not clear why you are pursing the framework to make changes for you since some other tools in your application might not be aware of this feature in this specific library. As I said in that other our discussion: see if custom GenericMessage with some smart toString() implementation can be done. This can be supplied with a custom AbstractIntegrationMessageBuilder created by the custom MessageBuilderFactory registered as a bean with the IntegrationUtils.INTEGRATION_MESSAGE_BUILDER_FACTORY_BEAN_NAME.

Another solution where you hide PII at all is via old good Claim Check pattern: https://docs.spring.io/spring-integration/reference/6.4/claim-check.html. Because the real question is: why that PII is readable in your application at all? The integration solution is usually a payload-agnostic and only transfers data from one place to another.

We cannot accept your suggestion about failedMessage: there some places in the framework where we check if it present or not to decide to wrap into a new exception or not. Either way, that's not the library or message itself concern. That's really about the data and only your project may know what is PII and what is not.