expirationWarningThreshold

[Brent Putman]

On 5/24/17 2:28 PM, Cantor, Scott wrote:
> (mentally I would not think of it as "not expiring" but "still returns data even if expired"),

Yes, I was sloppy with my phrasing.


>  but I'm not concerned about the weird conflation of two edge features, one of which is pretty much never on until the warning happens and then you turn it on to avoid things breaking.

By way of explanation, the reason I did it that way was:  The "already
expired" check is actually not really that (as you sort of say), it's
"is it currently valid per isValid(XMLObject)".  isValid() is the
(only) thing that evals requireValidMetadata. When the latter is false,
isValid() just trivially returns true, otherwise it does the actual
validation (which right now is just validUntil checks, although a
subclass could override).  So isValid() is what is actually going to
discard (or not) candidate metadata which is expired (or otherwise
deemed invalid) during resolution requests, so it made sense to me to
use that for the root expiration check for the new logging, to keep the
logic in sync.

And then in order to make the other 2 new logging cases consistent with
that, I also conditionalized them based on requireValidMetadata, since
it's going to be the same isValid() logic that is relevant to whether
the metadata is actually going to expire in the future.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20170524/226fd1f5/attachment.html>