Ex: Re: shibboleth.expiring-password.Condition in v4

[Paul B. Henson]

> From: Cantor, Scott
> Sent: Friday, August 28, 2020 12:34 PM
>
> > whether for any particular use case I'm supposed
> > to be using the JavaScript API or the Java API.
> 
> The latter, always

Ah, ok. That's probably one of the reasons I always have so much trouble with the scripting interface. I usually approach it as "how do I do this in JavaScript", I guess I need to do it in Java instead and then translate it into the JavaScript accessor script.

> >  So instead of using that API, I should do something like:
> 
> Yes.

Cool. I updated my configuration to use that mechanism and it seems to be working.

> >    I think the default formatter that comes with the distribution
> ("yyyyMMddHHmmss'T'") is broken though.
> 
> If it's not a legal Java formatter, then it's broken, yes. If it's valid for some
> format, then it's just what it always was, an example to modify since no format
> is standard.

Hmm. Well, it is a valid formatter, so it is not broken in that sense. However, from what I can tell, it is not a format that will ever produce a time valid for the use case. Based on the error message:

2020-08-27 20:24:26,981 -                                                       
10.104.223.168/node01lpe4jz8ageye1mygwvz0rmlq30 - WARN                          
[net.shibboleth.idp.profile.logic.DateAttributePredicate:208] -                 
20201217075900T is not a valid date for the configured date parser              
java.time.DateTimeException: Unable to obtain Instant from                      
TemporalAccessor: {},ISO resolved to 2020-12-17T07:59 of type                   
java.time.format.Parsed                                                         
        at java.base/java.time.Instant.from(Instant.java:378)                   
        Caused by: java.time.temporal.UnsupportedTemporalTypeException:         
        Unsupported field: InstantSeconds                                       
                at                                                              
                java.base/java.time.format.Parsed.getLong(Parsed.java:203)     

The formatter successfully parsed the date, but it failed to be converted into an instant because it had no time zone. So while it is not an invalid formatter, it is broken in the sense that it will never generate a time that can be converted into an instant because it has no time zone in it. So when somebody sees that example, and gives it an attribute that perfectly matches the default format, it will fail. In a very confusing way.