6:11 p.m.
Hi-
After upgrading our Satosa to the latest, I am getting some deprecation warnings in the
Satosa log.
I'll address the other 2 warnings later (I think they are related to python3), but for
now I'm interested in how to use the new hasher microservice. I am not having much
luck finding documentation for it.
The warning in the log is this:
"/usr/local/lib/python3.6/site-packages/satosa/base.py:56: DeprecationWarning:
'USER_ID_HASH_SALT' configuration option is deprecated. Use the hasher
microservice instead."
Can you point me to some help in using that new microservice?
Thanks!
9:41 p.m.
Hello,
On Tue, 27 Nov 2018 at 20:11, Paul Caskey <pcaskey at internet2.edu> wrote:
Hi-
After upgrading our Satosa to the latest, I am getting some deprecation warnings in the
Satosa log.
I’ll address the other 2 warnings later (I think they are related to python3), but for
now I’m interested in how to use the new hasher microservice. I am not having much luck
finding documentation for it.
The warning in the log is this:
“/usr/local/lib/python3.6/site-packages/satosa/base.py:56: DeprecationWarning:
'USER_ID_HASH_SALT' configuration option is deprecated. Use the hasher
microservice instead.”
Can you point me to some help in using that new microservice?
The hasher microservice replaces a mechanism that existed in SATOSA
for no good reason. SATOSA would unconditionally hash the name-id
value (used to be called user_id, changed to subject_id) before giving
it to the response microservices and finally the frontend that would
forward the authn-response to the SP. This resulted in problems and
was moved out as a microservice. In the form of a microservice it can
now be chosen whether this should take place or not; and the
configuration has been extended to define if this should take place
when a specific SP-entityid is met.
Along with this, some configuration options are no longer needed. One
of them is USER_ID_HASH_SALT. As SATOSA is not performing the hash, it
does not need that configuration option anymore. If there is a reason
that you need that hash to take place, the USER_ID_HASH_SALT should
now be defined at the hasher microservice configuration and it can
again be defined to different value per SP-entityid. If you do not
have such a need for the hash, you can just remove the configuration
option from the main configuration file ('proxy_conf.yaml') and the
warning will be gone.
(The same holds for the 'hash:' configuration option that provided a
list of attributes whose values would be hashed. This option used to
be defined in 'internal_attributes.yaml'.)
There is an example configuration of the hasher microservice here:
https://github.com/IdentityPython/SATOSA/blob/master/example/plugins/micros…
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
10:19 p.m.
Thanks, Ivan.
microservice. In the form of a microservice it can now
be chosen whether
this should take place or not; and the configuration has been extended to
define if this should take place when a specific SP-entityid is met.
Along with this, some configuration options are no longer needed. One of
them is USER_ID_HASH_SALT. As SATOSA is not performing the hash, it does
not need that configuration option anymore. If there is a reason that you
Removing USER_ID_HASH_SALT from proxy_conf.yaml cleared one of the two hash-related
deprecation warnings I was seeing.
I am still seeing the following and, so far, am not able to track it down:
"/usr/local/lib/python3.6/site-packages/satosa/deprecated.py:173: DeprecationWarning:
UserIdHashType is deprecated and will be removed.
_warnings.warn(msg, DeprecationWarning)"
I don't see that anywhere in my config files...
Any pointers?
Thank you!
11:41 p.m.
On Fri, 30 Nov 2018 at 00:19, Paul Caskey <pcaskey at internet2.edu> wrote:
Thanks, Ivan.
I can only guess that some part of your code (most probably a
microservice) is using this component. Do you have any custom
microservices?
--
Ivan c00kiemon5ter Kanakarakis >:3
microservice. In the form of a microservice it
can now be chosen whether
this should take place or not; and the configuration has been extended to
define if this should take place when a specific SP-entityid is met.
Along with this, some configuration options are no longer needed. One of
them is USER_ID_HASH_SALT. As SATOSA is not performing the hash, it does
not need that configuration option anymore. If there is a reason that you
Removing USER_ID_HASH_SALT from proxy_conf.yaml cleared one of the two hash-related
deprecation warnings I was seeing.
I am still seeing the following and, so far, am not able to track it down:
"/usr/local/lib/python3.6/site-packages/satosa/deprecated.py:173:
DeprecationWarning: UserIdHashType is deprecated and will be removed.
_warnings.warn(msg, DeprecationWarning)"
I don't see that anywhere in my config files...
Any pointers?
4:39 p.m.
Thanks.
I can only guess that some part of your code (most
probably a
microservice) is using this component. Do you have any custom
microservices?
In addition to the satosa_microservices package from idpy, we have 3 small microservices.
I do not find the text "UserIdHashType" anywhere in any of the code. Can you
tell me what else I could look for?
Thanks again!
1:13 p.m.
On Fri, 30 Nov 2018 at 00:19, Paul Caskey <pcaskey
at internet2.edu> wrote:
I think the problem is that the deprecation warning is always going to
be shown during startup of SATOSA because it is part of a class that sub
classes enum.Enum and so it is evaluated during the module load:
root at b3fce00a13ea:/tmp# python3
Python 3.5.3 (default, Sep 27 2018, 17:25:39)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license"
for more information.
Thanks, Ivan.
I can only guess that some part of your code (most probably a
microservice) is using this component. Do you have any custom
microservices? microservice. In the form of a microservice it
can now be chosen whether
this should take place or not; and the configuration has been extended to
define if this should take place when a specific SP-entityid is met.
Along with this, some configuration options are no longer needed. One of
them is USER_ID_HASH_SALT. As SATOSA is not performing the hash, it does
not need that configuration option anymore. If there is a reason that you
Removing USER_ID_HASH_SALT from proxy_conf.yaml cleared one of the two hash-related
deprecation warnings I was seeing.
I am still seeing the following and, so far, am not able to track it down:
"/usr/local/lib/python3.6/site-packages/satosa/deprecated.py:173:
DeprecationWarning: UserIdHashType is deprecated and will be removed.
_warnings.warn(msg, DeprecationWarning)"
I don't see that anywhere in my config files...
Any pointers?
>> import satosa.deprecated
/opt/satosa/satosa/deprecated.py:173: DeprecationWarning: UserIdHashType is
deprecated and will be removed.
_warnings.warn(msg, DeprecationWarning)
>>
Put another way, I do not think there is anything a deployer can do to NOT
see this deprecation warning.
I think that is not ideal.
I understand why the __getattr__() method on UserIdHashType was defined and
the DeprecationWarning put in place there, but I think it is too aggressive.
Developers should be paying attention and know that UserIdHashType is
deprecated since it is defined in deprecated.py. I don't think we need
to display the DeprecationWarning if a developer tries to use UserIdHashType
in a piece of code.
And deployers will never have occasion to call UserIdHashType.
So I think if the developers should be aware of it and deployers will never
call it then the deprecation warning can be removed from the class.
If you agree Ivan let me know and I can file a bug and/or make a pull
request.
Thanks,
Scott K
2:52 p.m.
Hello,
I think the problem is that the deprecation warning is
always going to
be shown during startup of SATOSA because it is part of a class that sub
classes enum.Enum and so it is evaluated during the module load:
ah, that's an oversight on my part.
It is not Enum that is causing a problem, it is those two lines:
*
https://github.com/IdentityPython/SATOSA/blob/0c9626633b214a60d85811d3f7121…
*
https://github.com/IdentityPython/SATOSA/blob/0c9626633b214a60d85811d3f7121…
Those provide backwards compatibility with previous versions; where
things were, how things behaved. The deprecation warning is triggered
when UserIdHashType is loaded for the first time; which happens
whenever the satosa.deprecated module is loaded the first time.
I will push some changes to address this soon.
--
Ivan c00kiemon5ter Kanakarakis >:3
1991
days inactive
1998
days old
6 comments
3 participants
participants (3)
-
ivan.kanak＠gmail.com -
pcaskey＠internet2.edu -
skoranda＠sphericalcowgroup.com