Improved error logging #3016
Improved error logging #3016
Conversation
… of interpolating it directly (which is the same as using `String(describing:)`) so the logged errors show more information without displaying that information in error responses sent to clients.
gwynne
added
enhancement
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #3016 +/- ##
=======================================
Coverage ? 76.92%
=======================================
Files ? 211
Lines ? 7770
Branches ? 0
=======================================
Hits ? 5977
Misses ? 1793
Partials ? 0 Continue to review full report in Codecov by Sentry.
|
|
@gwynne Couldn't sensitive information contained stored in log files still be a concern in production? Not sure what "sensitive" information we are talking about here. Is it database connection details or something less concerning such as schema information? |
|
@madsodgaard this is only really converting the error to a better string - if the error contains sensitive information then yeah it will be logged, but in the same way that logging the whole request will leak sensitive info. We can't really police that as a framework and instead should provide best practices for logging and errors (i.e. errors should be fairly generic, log messages should be specific but either scrubbed from PII or using a custom backend combined with log metadata to ensure nothing is output |
|
In this case I did the update pretty much specifically for the sake of |
|
These changes are now available in 4.75.2 |
* main: (75 commits) Make Storage Sendable (vapor#3056) Add Sendable Conformances to undelying types (vapor#3054) Resolve issue vapor#2650 (vapor#2674) Fix for vapor#2574 Missing quote from value (vapor#2839) Allow specifying a timeout for client requests (vapor#3043) Update dependencies with known CVEs to the latest versions (vapor#3038) Create CODEOWNERS Improve error reporting for `EncodingError` and `DecodingError` (vapor#2981) Fix incorrect use of non-localhost connection in test Update README with new Sponsor (vapor#3025) Add `ContentContainer.decode(_:as:)` (vapor#3023) Fixed drain handler call order in case of asynchronous buffer handling (vapor#3009) Update README with new Sponsor (vapor#3024) Update README with new Sponsor (vapor#3020) Don't use UnsafeRawBufferPointer.withMemoryRebound(to:_:) before Swift 5.7.2 (vapor#3021) Avoid deadlocking websocket tests (vapor#3019) Update README with new Sponsor (vapor#3014) Fix `Range: bytes=0-0` header not working properly (vapor#3010) Remove use of HTTPBin (vapor#3017) Improved error logging (vapor#3016) ... # Conflicts: # Sources/Vapor/HTTP/Headers/HTTPHeaders+ContentRange.swift # Sources/Vapor/Utilities/FileIO.swift
Some kinds of errors provide additional "debug" information, which can give much more detail than the "plain" description of the error. In many cases this debug info can contain sensitive data, such as specifics about a database schema, so Vapor only uses the plain description when sending errors to clients (and in release environments, all details are suppressed).
To date, the plain description has also been used for logging errors. This can make it very difficult for developers to figure out what's going wrong with their code if the error in question only provides meaningful information in its debug data - for example, the PostgreSQL database driver implementation does this rather than relying on a higher-level layer like Vapor to obfuscate potentially sensitive information. This PR changes the logging of errors to include the debug information (and only the logging; the responses sent to clients are unchanged).