Problem configuring strength ranges

[katapofatico]

Hello :)

I am using 1.2.2 version, with messages configuration via "shortPass", "badPass", "goodPass", "strongPass" parameters. It works correctly.

Now I want to configure the plugin to evaluate as "Strong password" a password rated with 60%:
a) To show a message "Strong" with a password rated with 60%
b) To show green color with a password rated with 60%
I had several problems trying it, therefore I have downloaded 2.1.0 version and I can't get it.

a) Configuring messages
Reading documentation, I think that "steps" parameter is the point, and his second array position looks like it replace "shortPass", "badPass", "goodPass", "strongPass" parameters. Then,

my code...

this.passwordInput.password({
                steps: {
                    13: 'Very bad',
                    33: 'Bad',
                    45: 'Medium',
                    60: 'Strong',
                },
                containsField: 'La contraseña contiene un dato personal',
                enterPass: 'Escribe tu contraseña',
                showPercent: true,
                showText: true,
                animate: true,
                animateSpeed: 'fast',
                field: false,
                fieldPartialMatch: false,
                minimumLength: 9
            });

...and the result:

It appears that "steps" configuration don't works as expected.

b) Configuring bar colors
The example in documentation it's confusing:

customColorBarRGB: {
    red: [0, 240],
    green: [0, 240],
    blue: 10,
  } // set custom rgb color ranges for colorbar.

I have checked these tests before write this issue:

• it('can use custom rgb colorbar values for a good password')
• it('can use custom rgb colorbar values for a bad password'),

... but I don't understand the meaning of array values, neither how to distingsh each range color configuration.

Can you please guide me to solve it? Maybe you can clearify documentation, or even add to examples page an example about this.

Thanks a lot!

[Òscar Casajuana]

I'll need to check that first part (a) because it's tested and it works (or appears to be working).

For the second part (b), if I'm not wrong, the array values are the range of these specific colors in the rgb spectre, may be a little tricky to tweak them.

I think it would be a good moment to add that note in the readme @jhoover4 😅.

[Jordan Hoover]

That makes sense and can do!

@katapofatico I've tested it on my computer and it looks like things are working normally. Are you sure that the element is being selected correctly? It looks like the values you're showing in your image are the default ones, not the ones you've passed in.

Also do you understand the color ranges now? If not let me know!

[Jordan Hoover]

Updated README PR: #41

[katapofatico]

Hello @jhoover4 I have found a clue about the reffered "a) Configuring messages" problem:

Testing this configuration:

steps: {
    // Easily change the steps' expected score here
    1: 'Really insecure password',
    2: 'Weak; try combining letters & numbers',
    3: 'Medium; try using special characters',
    4: 'Strong password',
}

If I use v2.1.0/dist/password.min.js:

and if I use v2.1.0/src/password.js:

Therefore, there is a problem in minified file. Can you test this case, please?

[Òscar Casajuana]

Doh. That happened due to the travis.yaml file removal. I forgot to update the gitlab-ci stuff to minify the file there.

The thing is that, due to non related personal problems, I’ve no computer these days... I‘ll see what I can do anyway.

[katapofatico]

@elboletaire Take it easy, I'm using by now unminified file in production. I'll receive your updates, thanks!

[Jordan Hoover]

Oh shoot thanks for catching this @katapofatico sorry I didn't realize that before! @elboletaire let me know if you want me to help out with the CI?

[Òscar Casajuana]

Hey @jhoover4 that would be awesome. I already have my new computer but I still need some time before I can spare time in open source.

What we were doing before is still in the build.sh script. I'd remove that file and directly use .gitlab-ci.yaml for everything. We only need to define a new (build) stage which should only run on master and tags. That stage should run a compilation, move the files and make a commit with those changes. It's important to add a [skip ci] in the commit message to avoid gitlab-ci compiling it over and over again.

Right now, tags are being compiled in my machine when using npm version, but I think it's a good moment to change that behavior too and add another gitlb-ci stage so every time we publish to a tag, it gets automatically published to npm.

[Jordan Hoover]

Ah okay. I work with Gitlab at work so I know exactly how to do it. Will I need Gitlab access though to check it?

[Òscar Casajuana]

@jhoover4 You can locally use gitlab-runner with docker to try whatever you need in .gitlab-ci.yaml, no need for permissions in gitlab side 😃

[Òscar Casajuana]

Files in dist have been updated. Could you please check that it's working as expected @katapofatico ?

There's a side issue with the build script, but I'm creating a new issue for that.