Shibboleth IdPv3 administrative urls

[Peter Schober]

* Michael A Grady <mgrady at unicon.net> [2015-10-22 16:58]:
> So the following appears to work:
> 
>  ../idp/profile/admin/reload-service?id=shibboleth.AttributeResolverService
> 
> I guessed that the corresponding argument/value set for reloading
> metadata would be the 'id' of the MetadataProvider
> 
>   ./idp/profile/admin/reload-metadata?id=MyLocalMetadataFile
> 
> and that appears to have worked. Is the above correct, and anything
> else interesting about using the above endpoints that may not
> otherwise be obvious without looking at the code?

All of this is documented, at
https://wiki.shibboleth.net/confluence/display/IDP30/ReloadableServices

FWIW, initially I didn't have a plain http listener on port 80 (an IDP
only needs to listen on port 443) so the reload and status scripts didn't
work as is.
But the error message from that invocation was clear enough that I
assembled a set if shell aliases that did the same think using cURL.
E.g.:

curl -s -k 'https://localhost/idp/status'
curl -s -k 'https://localhost/idp/profile/admin/reload-service?id=shibboleth.AttributeFilterService'
curl -s -k 'https://localhost/idp/profile/admin/reload-service?id=shibboleth.AttributeResolverService'
curl -s -k 'https://localhost/idp/profile/admin/reload-service?id=shibboleth.LoggingService'
curl -s -k 'https://localhost/idp/profile/admin/reload-metadata?id=your.MetadataProvider.id'

I later did add a listener on port 80 on the loopback interface only,
to make the scripts work as documented. Seems easy enough and allows
anyone following the docs to reload stuff, w/o local knowhow.

Reloading works wonderfully and at least on Tomcat8 is absolutely
essential, as restarting the IDP (or context) would take ages, so that
would be absolutely prohibitive for testing purposes.
-peter