arsenjavaee / java-password-complexity-validator Goto Github PK

Instead of having the caller depend on parsing or display english language 
exceptions, set a code (an enum for example). Then you could either dispense 
with most of your exception throwing or at least include the code in the 
exception

The Dictionary Validator is combined into one project, and it is refactored 
too. Although I don't have time to test, it should all work now.

Typical call

// Typically you'd cache this in a singleton
DictionaryPasswordValidator dpv =DictionaryPasswordValidator.getInstance(); // 
there's an optional getInstance() method with the accuracy, minDictionaryLength 
arguments

//... or at least this
PasswordComplexityValidtor pcv=new 
PasswordComplexityValidator(PasswordComplexityPolicy.DEFAULT);

And now, you could use the pcv as a cache singleton, and call it any time with

pcv.validatePassword(String newPassword, ArrayList<String> 
oldPasswordsNewestToOldest)


I believe these are far more best practice than the original structure.

So you can disable checks. Alternatively with the configuration object 
mentioned in previous issue, you can have more explicit boolean on/off of 
these. Example: If you don't care how many special characters are there, 
there's no way to turn this off

What steps will reproduce the problem?
1. Enter a password over max length
2. Enter a password at max length

What is the expected output? What do you see instead?
1. See a error message that password is over max length
2. Change accepted

What version of the product are you using? On what operating system?
1.1, Ubuntu 12.04LTS, Ubuntu 14.10 LTS and Windows 8.1

Please provide any additional information below.

The error message makes no sense, "at less than".  Rather have something along 
the lines of "no more than".


if (passwordLen > maxPasswordLength) {
            throw new PasswordComplexityException("The password must be at less than " + maxPasswordLength + " characters in length.");
        }

This is a major refactoring. The dictionary stuff doesn't work yet,because I 
haven't had time to look at the code. Have a look at it, and see if you like it.

1. Policy object, immutable 
2. Main validator, immutable, uses builder
3. Main validator separates out dictionary concerns
4. Exceptions include an enum code, far better than parsing messages
5. Logging code removed - extraneous to class.


Usage: Typically you'd call newInstance() once and stick that in a cached 
singleton. newInstance requires a Policy and a Dictionary (the latter of which 
can be null). It's also assumed the Dictionary was built previously

Instead of a gigantic constructor, consider using a public static 
getInstance(). You could provide several with various choices by default. In 
addition, consider having a configuration object for such a large number of 
inputs