2- try to filter attributes (either with aacli or via login to a SP) => no attribute released (normal becase the 'registrars' attribute is mispelled
3- Fix de value "https://whatever.org/" 3- ./reload-services.sh -id shibboleth.AttributeFitlerService 4- Still no attributes released 5- stop/start web container => attributes are now released
Environment
Tested on Linux CentOS 7.9 / Tomcat 9.0.45 / IdP 4.1.0
Activity
Scott Cantor
June 17, 2021 at 2:44 PM
@Geoffroy ARNOUD We can't reproduce this so far, do you have any more input? If not, we'll need to close out.
Rod Widdowson
April 26, 2021 at 3:55 PM
I've tried this locally and had no luck with reproducing it.
I'll note that in our reproducer steps you have mis-typed the service name (shibboleth.AttributeFitlerService) but that would have been very obvious.
You may want to check
That the service is being reloaded (as per the logs and as per the status page)
That the file you think is being reloaded really is (by introducing a schema error into it, reloading and watching for errors in the log)
I'm sorry but without being able to reproduce this locally I am at a loss over how to proceed.
Scott Cantor
April 26, 2021 at 3:15 PM
I'd be checking my log for errors during the reload, there's no possible way this can be "partially" reloading. It's all or nothing. Nothing means that it didn't actually reload successfully.
Reloading AttributeFilterService when an attribute value is changed has not effect
Steps to reproduce:
1- configure the following filter policy with a mistake in the registrars attribute (ex: missing ending ‘/‘)
<PolicyRequirementRule xsi:type="RegistrationAuthority" registrars="https://whatever.org"/>2- try to filter attributes (either with aacli or via login to a SP) => no attribute released (normal becase the 'registrars' attribute is mispelled
3- Fix de value "https://whatever.org/"
3- ./reload-services.sh -id shibboleth.AttributeFitlerService
4- Still no attributes released
5- stop/start web container => attributes are now released