-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Flag to allow application data in logging #1374
Comments
@lukewaters please work with @anpete to get some direction on this one |
@rowanmiller @anpete @ajcvickers need to find an owner for this. |
Didn't we handle this with a log level that applies across all technologies? |
This should probably be replaced by a bug to switch from logging to event notification. |
@rowanmiller I did add a Debug log level and a minimum level to logging a couple months ago, the minimum level prevented more detailed level messages from being distributed to registered loggers for security purposes |
@lukewaters Can we assume that the state of check boxes in the check list is up to date? Thanks! @anpete Yeah probably. I see that as part of what the new owner would need to figure out. Are you volunteering? 😄 |
Yes I am. :-) |
@divega The flag is in place, and I Added the LogParamenters flag in RelationalLoggingExtensions I think EF also logs a message whenever DbContext is initialized |
Thanks again! |
@anpete all yours! |
- New DbContextOption "LogSqlParameterValues()" replacing use of Debug log level to control sensitive data logging. - Use a wrapping ILogger<T> in relational to transparently enforce sensitive data logging. - More consistentizing of logging usage, DI etc. - Better structured logging of DbCommands. - Use assembly scoped enums for event ids. - Use event ids everywhere. Fix #1374, #2490
- New DbContextOption "LogSqlParameterValues()" replacing use of Debug log level to control sensitive data logging. - Use a wrapping ILogger<T> in relational to transparently enforce sensitive data logging. - More consistentizing of logging usage, DI etc. - Better structured logging of DbCommands. - Use assembly scoped enums for event ids. - Use event ids everywhere. Fix #1374, #2490
- New DbContextOption "LogSqlParameterValues()" replacing use of Debug log level to control sensitive data logging. - Use a wrapping ILogger<T> in relational to transparently enforce sensitive data logging. - More consistentizing of logging usage, DI etc. - Better structured logging of DbCommands. - Use assembly scoped enums for event ids. - Use event ids everywhere. Fix #1374, #2490
From a security point of view we decided that, by default, both the message action and state passed to ILogger.Write should not contain any application data. That is, data that comes from the data store or may be supplied by an end user of the application. Depending on the application, this data may contain sensitive information (usernames, credit card numbers, etc.). Examples include, results from queries, values stored in entity instances, and constant values used in LINQ expressions.
We'll have a simple flag that can be enabled to allow this information to be included. This is especially useful for logging queries, where it is helpful to have the parameter values logged along with the query.
This work item includes:
We should try and add this in a way that makes it easy to use it for future logging that we add.
The text was updated successfully, but these errors were encountered: