Skip to content
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

Closed
1 of 4 tasks
rowanmiller opened this issue Jan 9, 2015 · 10 comments
Closed
1 of 4 tasks

Flag to allow application data in logging #1374

rowanmiller opened this issue Jan 9, 2015 · 10 comments
Assignees
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-enhancement
Milestone

Comments

@rowanmiller
Copy link
Contributor

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:

  • Creating the flag (off by default)
  • Reviewing existing logging to make sure it honors the flag
  • Writing a warning to the log when the flag is enabled (once per context, ServiceProvider, or whatever is easiest)
  • Wherever data is filtered out of a message, include a message in place of the data letting folks know they can enable the flag to get the data (and a warning that it may result in logging sensitive info)

We should try and add this in a way that makes it easy to use it for future logging that we add.

@rowanmiller
Copy link
Contributor Author

@lukewaters please work with @anpete to get some direction on this one

@divega
Copy link
Contributor

divega commented Jun 30, 2015

@rowanmiller @anpete @ajcvickers need to find an owner for this.

@rowanmiller
Copy link
Contributor Author

Didn't we handle this with a log level that applies across all technologies?

@anpete
Copy link
Contributor

anpete commented Jun 30, 2015

This should probably be replaced by a bug to switch from logging to event notification.

@lukewaters
Copy link
Contributor

@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

@divega
Copy link
Contributor

divega commented Jun 30, 2015

@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? 😄

@anpete
Copy link
Contributor

anpete commented Jul 1, 2015

Yes I am. :-)

@lukewaters
Copy link
Contributor

@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

@divega
Copy link
Contributor

divega commented Jul 1, 2015

Thanks again!

@divega
Copy link
Contributor

divega commented Jul 1, 2015

@anpete all yours!

@divega divega removed the 2 - Done label Aug 12, 2015
@rowanmiller rowanmiller modified the milestones: 7.0.0-rc1, 7.0.0 Sep 17, 2015
anpete added a commit that referenced this issue Oct 1, 2015
- 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
anpete added a commit that referenced this issue Oct 1, 2015
- 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
anpete added a commit that referenced this issue Oct 1, 2015
- 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
@anpete anpete closed this as completed in 9da7a3c Oct 1, 2015
@ajcvickers ajcvickers added the closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. label Oct 15, 2022
@ajcvickers ajcvickers modified the milestones: 1.0.0-rc1, 1.0.0 Oct 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-enhancement
Projects
None yet
Development

No branches or pull requests

5 participants