-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(soap): remove logging of soap request and response #3848
fix(soap): remove logging of soap request and response #3848
Conversation
ea53aaf
to
0ce52ff
Compare
@@ -138,7 +138,6 @@ private ClientInterceptor[] buildInterceptors( | |||
List<ClientInterceptor> interceptorList = new ArrayList<>(); | |||
handleAuthentication(authentication).ifPresent(interceptorList::add); | |||
handleSoapHeader(soapHeader, namespaces).ifPresent(interceptorList::add); | |||
interceptorList.add(new LoggingInterceptor()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understand correctly, the customer does not want sensitive information to be logged.
However, the logging interceptor only uses the log level DEBUG, so the actual problem is on the customer side. I would vote for keeping this logging so that the debugging of connector issues is possible with the log.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Log/store PII is also forbidden (GDPR etc.), which might happen if we keep this line. Regardless of the log level, we just can't store this information.
You might be right, but I just wanted confirmation here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right in general.
In the last days, I worked with a customer on an issue and we required spring security filter details to be logged.
Spring solves this like this:
- All logging is TRACE
- There is a parameter that you have to set so that the logging will happen.
If we introduce a parameter, we can ensure that no confidential stuff will be logged "by mistake". Also, we are aligned with industry standards then.
This is pretty much what @mathias-vandaele suggested in the first place, so sorry for re-iterating
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All logging is TRACE
There is a parameter that you have to set so that the logging will happen.
Yea, I get this part :D But we can still log PII (using TRACE), which is from my knowledge simply forbidden (trace or info is not relevant).
I might be wrong though, so feel free to ignore my comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, apache http logs everything when being set to log level debug, so it is not forbidden :)
From my experience, the operations team has to ensure that they run compliant.
0ce52ff
to
124ff7b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
124ff7b
to
881c6ad
Compare
Description
Remove logs that could be showing sensitive data (request, response)
Related issues
closes #https://github.com/camunda/team-connectors/issues/965
Checklist
no milestone
label.