feat: ✨ Add leapday_expiry and weekend_expiry validation

[cdtomkins]

Added two ops-friendly checks - leapday_expiry and weekend_expiry validation

[bradh11]

Just thinking about this - does it make more sense as its own validator instead? The expiry validator is mostly focused on whether the cert has gone beyond (or is approaching) its expiration date.

It seems the focus on this enhancement is to focus on “special days” like does it expire on a weekend, or on a leap year date. If you created a validator for “special dates” (or you could come up with a better name) then it could potentially be more universally useable. For example with a “special dates” validator you could in theory also check a list of dates that the user passes on as a validator argument (similar to how sans one works).

so the built ins for the new validator would include

• Weekend expiration check
• Leap day expiration check
• Evaluated list of dates (maybe a dict input for key/value such as holiday_name/date) - passed in as arts

this would also allow you to get more details in for “warnings” for the particular cases.

[bradh11]

For reference, here is the documentation on how to pass Args to a validator.

https://certmonitor.readthedocs.io/en/latest/usage/validator_args/

[cdtomkins]

Yes, I agree that it would work nicely as an additional validator. I will do that. We're zero-dependency here obviously, but in relation to the functionality you described, I will make it very easy to pass holidays from, say, the Holidays library. Sound good?

[bradh11]

Yes, I agree that it would work nicely as an additional validator. I will do that. We're zero-dependency here obviously, but in relation to the functionality you described, I will make it very easy to pass holidays from, say, the Holidays library. Sound good?

Yes. I would say make the validator in such a way that you just pass an arbitrary list of dates in. Then it would be up to the user as to what meaning the dates actually have and they could derive it from some other library if they choose. That way we stay zero dependencies and leave it up to the user. I’d stay away from calling it holiday or using a specific term since the use cases could be any date deemed important or appropriate to warn against an expiration happening that particular day (example of a non holiday date might be like the IT admins grandparents anniversary, or the day they have to renew their drivers license :-) ).

You’ll need a way for the user to pass in the meaning along with the dates so that you can populate the warning field appropriately.

[
{“my_anniversary”: date_obj},
{“international_ice_cream_day”: date_obj},
etc…
]

Something like this ☝️

[cdtomkins]

I will resubmit this with a new PR to simplify merging.

[bradh11]

Sounds good. Look forward to it