Closed darkstarx closed 1 month ago
I can expose the logger but in order to hide credentials knowledge of the SMTP is necessary. As you mentioned the passwords are for instance base64 encoded and a simple search / replace is not possible.
IMO a better solution would be an option to hide sensitive details. We could have multiple flags for the logger.
As it might take some time until I can implement this, I could expose the logger for now with a deprecation flag. In that case you would need to adapt your code when I make the logger private again.
Is this a solution you are interested in?
Well, that's great that you use the logging
package to notify about all internal events, and that you use different loggers (like 'Connection', 'mailer_sender' etc.) to classify these events. It can help to manage which events should go to the log just using internal settings of the logging
package (like hierarchicalLoggingEnabled
, level
, onRecord
etc.). But to use these settings I need access to these loggers.
For example, you could place all loggers in one module that would be used in different internal modules, and this module could be exposed to setup these loggers. Another way is making some log level setters for these loggers, like it is made in the hotreloader
package for example. May be you could suggest another approach.
Anyway, it would be nice to have a possibility:
Thanks.
Hi darkstarx!
You don't need access to the loggers. You can create the loggers again. It's only important to use the same name.
You can for instance configure the Logger('mailer_sender')
logger in you main by simply creating the logger again:
final logger = Logger('mailer_sender');
logger.level = Level.FINE;
logger.onRecord.listen((record) {
print('[**SENDER**]${record.message}');
});
I will keep this issue open, but change it to "provide a way to hide credentials in the logs"
Hm. I just wonder to know, how can you declare, what I need? I need to manage which information among all of those the package provides should go to the log of the application. The original title of the issue was about that and I mean it. If there is no such mechanics in this package, I have just two options: to find another package or to fork this package and implement what I really need and publish as an alternative package.
Hi @darkstarx !
You wrote:
It can help to manage which events should go to the log just using internal settings of the logging package (like hierarchicalLoggingEnabled, level, onRecord etc.). But to use these settings I need access to these loggers.
As written in my comment, you can do this now, without having access to the loggers. Having found a solution for your issue, I would usually simply close it. I however thought, that having a way to exempt credentials from logging would be a good idea, and renamed the issue.
As a library maintainer I will not simply change code to "fix" an issue. My goal is to understand the problem. Your stated problem was to prevent leaking credentials. Simply exposing the loggers might fix this problem for you, but many other developers will not know enough about SMTP to prevent this, even with exposed loggers.
Additionally you can already do everything you want with loggers, without me exposing them.
Finally: I have informed you, that your style is aggressive / impolite. If this is not your intention, use chatgpt (or something similar) to improve your text. I will ignore any impolite messages from you in the future.
Your stated problem was to prevent leaking credentials.
Wrong. It was just an example of benefits of the feature of managing the loggers. The really stated problem was that the package doesn't provide possibility to manage the log it produces.
Closed with this solution https://github.com/kaisellgren/mailer/issues/253#issuecomment-2238399729
Hi! Could you make the
_logger
accessible outside the library please? It would be helpful to manage the level of logs specifically for your logger. When using auth login, the login and password are in the log (just base64 encoded) which can be shown in some cases, e.g. in crash-management reports and so on. I'd like not to show this part of logs in the production builds.