Keep in mind the PostInstall perl script might be doing it differently too.
Jonathan G
On 8/18/20, 12:00 PM, "ocket 8888" <ocket8...@gmail.com> wrote:
> We could probably get away with doing it over minor versions too.
I wouldn't be opposed to that either. If it mattered. Because:
> How can the database enforce password length?
It... seems like it can't. I just looked and it appears that those are
encrypted in the API and stored at a fixed length. That means the user
password I'm thinking of is being inserted into the database directly...
Disregard!
On Tue, Aug 18, 2020 at 11:18 AM Eric Friedrich <eric.friedric...@gmail.com>
wrote:
> How can the database enforce password length?
>
> On Tue, Aug 18, 2020 at 1:08 PM Dave Neuman <neu...@apache.org> wrote:
>
> > Seems reasonable however I don't think we need to wait for major
version.
> > We could probably get away with doing it over minor versions too.
> >
> > On Tue, Aug 18, 2020 at 11:00 AM ocket 8888 <ocket8...@gmail.com> wrote:
> >
> > > Currently, Traffic Portal restricts the passwords entered to a minimum
> > of 8
> > > characters. This restriction is not mirrored in the database (and
> > possibly
> > > not in the API, but that can be fixed at the same time as the db if
> > that's
> > > the case). I propose that we add this restriction to prevent
> potentially
> > > wildly insecure passwords from existing for Traffic Ops clients.
> > >
> > > This would entail including a notice in the 5.0 release, probably in
> the
> > > changelog, one or four places in the documentation, and possibly
> another
> > > email to the users list after the 5.0 - to notify - and 6.0 - to
> remind -
> > > releases. Then, a migration can be added to 6.0 to restrict password
> > length
> > > at the database level, giving users a full major upgrade cycle to make
> > > their data compliant with the new restrictions.
> > >
> >
>
