2 ms·
> If you are building an API, having a mechanism that provides detailed logs—including the POST bodies passed to the API—is invaluable. I'm not sure about this
by ickyforce 5y ago
> If you are building an API, having a mechanism that provides detailed logs—including the POST bodies passed to the API—is invaluable.
I'm not sure about this one. I explicitly avoid logging bodies because they can contain sensitive or proprietary information. But for the past few years I've been working at companies where it was not ok to look at customer data without customer's approval, that probably skews my ways.
- simonw 5y agoYeah, you absolutely shouldn't log POST bodies that contain information which shouldn't be made available to your developer team for debugging purposes. When I implement this pattern I make sure not to log the incoming authentication token - I decode it first and log the user ID. I don't want logs that include secret tokens that could be used to impersonate an end-user. There are patterns you can use to help with automated redaction: one that I particularly like is using a prefix on fields that should be redacted before being logged - "private_password": "..." for example. You can also redact things on a specific deny-list, but it's relatively easy for someone to forget to update that. I like to make the redaction mechanism as obvious as possible.
- joshxyz 5y agoBit skewed on this one too. There are cases where the bug is account specific. I think the compromise here is on shorter retention policy if they contain sensitive info, or granular log access permissions. Anyone informed better on approaching these scenarios please?