stuartpb
commented
7 years ago I'm going to go forward with this now, because:
- It doesn't require that many rewrites
- It solves at least one open issue directly, and makes a few others much easier
- It makes profiles more flexible and capable of accommodating something they can't do in the current design
So, I'm looking at #96, and redefining
previousso that it doesn't have a polymorphic value (per #164) seems like it'd knock out two schema-unfriendly birds with one stone (per #146, and following the lead of #149).Moreover, there are two kinds of "previous password" restrictions that a site can put in place: there's "the last X passwords", as the value is currently defined - but there's also time-based recency (similar to #257), where a site can blacklist passwords used in the last few months (for instance).
As such, I think this field should get split into
password.value.blacklist.previous.countandpassword.value.blacklist.previous.period, where the former is a number, and the latter is a timespan string (where I'm thinking "mo" might be used to represent months in a way that can't be confused with minutes, though I'm also considering having "months" just be represented as a number of days times 30 unless it can be proven that that's not how they're counting months).This would also open up a more comfortable field for sidestepping the "JSON not having a way to represent
Infinity" problem noted in #200, by letting "all the passwords you've ever had" be represented asperiod: foreverinstead of a polymorphic value for the count.