Once you’ve got your instance you can authenticate and authorise with it just like any AuthProvider.

The out of the box config assumes the usage of the collection with name "user", the username stored and read by field "username"
some others.

In order to avoid duplicates of user names your "user" collection should have a unique index on "username". In order
to do this you should run the following snippet on your mongo server:

db.user.createIndex( { username: 1 }, { unique: true } )

The reason you should add the index is that due to the nature of mongo doing a query first to verify if a username is
already taken and then insert a document cannot be run as an atomic action. Using the index the code will try to
insert the row and fail if duplicate.

You can also change all the defaults for the mongo collection and column names using any of the methods:

The default implementation assumes that the password is stored in the database as a SHA-512 hash after being
concatenated with a salt. It also assumes the salt is stored in the table too. The field, where the salt is
stored can be set by setSaltField, the default is "salt".
You are able to change this behaviour by using setSaltStyle.
The HashStrategy you can retrieve by getHashStrategy.
By using this, you are able to set:
NO_SALT by which passwords are not crypted and stored
in cleartext. ( see the warning below! )
COLUMN, which will create a salt per user and store this
inside the defined column of the user. ( see the warning below! )
EXTERNAL, which will store only the crypted password in the
database and will use a salt from external, which you will have to set by setExternalSalt

If you want to override this behaviour you can do so by providing an alternative hash strategy and setting it with
setHashStrategy

Warning

It is strongly advised to use the EXTERNAL option.
The NO_SALT option is existing for development phase only and even the COLUMN option is not recommended, cause
salt and password are stored inside the same place!

Warning

As of 2018 OWASP recommends the usage of stronger encryption algorithms to hash user passwords for
this case you can change from the default (preserved for backwards-compatibility) to PBKDF2. For new projects
this should be the standard.

Authorisation - Permission-Role Model

Although Vert.x auth itself does not mandate any specific model of permissions (they are just opaque strings), this
implementation assumes a familiar user/role/permission model, where a user can have zero or more roles and a role
can have zero or more permissions.

If validating if a user has a particular permission simply pass the permission into.
isAuthorised as follows: