8:04 p.m.
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
9:51 p.m.
Hi Rainer and Hi all,
I agree the line, when I seen that PR closed I thought "too soon, too
quickly".
I'd like also to have talking error messages to the users, to help them to
contact the helpdesk support with something consistent.
Example:
"Unknow error" appear also when the error is well-know, like an
"IncorrectSignature" Exception.
I also do not appreciate the traceback stack message into the log file, it
should permitted only for unknow Exceptions.
Using logging infrastructure in my projects I found it very flexible in its
usage, an example here that prints also the line number where the event
happened:
https://github.com/UniversitaDellaCalabria/uniAuth/blob/master/django_idp/s…
I hope that your contributions will not be wasted, I'm also looking about
the opportunity to do some cherry-pick from your forks at branch, about things
that you are doing and I consider helpfulls and smarts.
Those lines of codes should not be forget!
Il giorno dom 14 lug 2019 alle ore 22:04 Rainer Hoerbe <rainer at hoerbe.at>
ha scritto:
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
Cheers, Rainer
_______________________________________________
Satosa-dev mailing list
Satosa-dev at lists.sunet.se
https://lists.sunet.se/listinfo/satosa-dev
--
____________________
Dott. Giuseppe De Marco
CENTRO ICT DI ATENEO
University of Calabria
87036 Rende (CS) - Italy
Phone: +39 0984 496961
e-mail: giuseppe.demarco at unical.it
--
------------------------------------------------------------------------------------------------------------------
Il banner è generato automaticamente dal servizio di posta elettronica
dell'Università della Calabria
<http://www.unical.it/5x1000>
4:12 a.m.
Anfang der weitergeleiteten Nachricht:
Von: Giuseppe De Marco <giuseppe.demarco at unical.it>
I'd like also to have talking error messages to
the users, to help them to contact the helpdesk support with something consistent.
Example:
"Unknow error" appear also when the error is well-know, like an
"IncorrectSignature" Exception.
PR 257 tries to address this
I also do not appreciate the traceback stack message into the log file, it should
permitted only for unknow Exceptions.
This is almost a killer for external log processing, unless it it not strucutured.
Using logging infrastructure in my projects I found it very flexible in its usage, an
example here that prints also the line number where the event happened:
https://github.com/UniversitaDellaCalabria/uniAuth/blob/master/django_idp/s…
<https://github.com/UniversitaDellaCalabria/uniAuth/blob/master/django_idp/settingslocal.py.example#L79>
Yes, and it is already just a configuration thing.
- Rainer
1769
days inactive
1770
days old
2 comments
2 participants
participants (2)
-
giuseppe.demarco＠unical.it -
rainer＠hoerbe.at