Hi,
I would like to hear opinions about (rejected) Satosa PR #237. Can we put this on the
agenda?
Today I can talk only the first 20 minutes and will switch to listening only afterwards.
Cheers, Rainer
Anfang der weitergeleiteten Nachricht:
Von: Rainer Hoerbe <rainer at hoerbe.at>
Betreff: Granular Logging control
Datum: 14. Juli 2019 um 22:04:55 MESZ
An: satosa-dev at lists.sunet.se
Kopie: Ivan Kanakarakis <ivan.kanak at gmail.com>
If would like to discuss a logging feature that I would like to see in Satosa. I proposed
with PR 237 to add a log filter that would enhance satosa's logging capabilities. Ivan
rejected it for the (in general good) reason that the proxy should log everything and log
processing should be external.
I agree in general, but there are bits where I still think that they would be useful in
satosa. These are:
1. In production environments it is unlikely to push the full set of debug information to
a logging service. However, it might be useful to get debug level data on certain
selections. Usually that would be based in IP addresses, which should not be too
complicated to implement.
2. In a dev environment one is easily inundated with debug data. Shibboleth has a nice
feature providing logging levels for certain aspects, such as XML tooling, SAMl message
de-/encoding. I find this capability quite useful, because in my dev environment I do not
have an elaborate log processor. Attribute configuration in satosa could be helped by
selected messages.
If done properly, this change has following impact on all modules that instantiate a
logger:
1. refactor the satosa_logger wrapper back to the native logger with similar signature
2. add a log filter after each get_logger()
The logfilter (logging.Filter) is orthogonal to structured logging, or may even help to
improve it.
see:
https://github.com/IdentityPython/SATOSA/pull/237
<https://github.com/IdentityPython/SATOSA/pull/237>
Cheers, Rainer