Shibboleth FileBackedHTTPMetadataProvider
Tom Scavo
trscavo at gmail.com
Tue Mar 29 10:01:24 EDT 2016
On Tue, Mar 29, 2016 at 9:42 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>> Basically, I'm trying to understand the strategy around the backing
>> file. I assume the backing file is consulted if the HTTP request for
>> metadata fails. Is the startup strategy different than the normal
>> refresh strategy?
>
> A refresh would never, AFAIK, consult the backing file.
That's interesting. So the backing file is only used at startup?
If the backing file is used at startup, are all the configured filters
run on the backing file?
Why not ALWAYS use the backing file at startup, to speed the startup process?
>> If signature verification fails, is the backing file consulted or does
>> the process stop dead in its tracks?
>
> Stops dead.
I assume you mean "stops dead" in the sense that the refresh process
terminates. In any case, I assume the SP keeps running and tries
another refresh at a later time.
If the backing file is used at startup, and the signature on the
backing file can not be verified, startup fails, right?
> Filters run after an instance is in hand to filter.
Right, but there are fresh instances and cached instances, which is why I asked.
Thanks,
Tom
More information about the dev
mailing list