The imports are done in the app_files variable.

Patch the call of the functions located in the views.images module in the download_target_folder() function

This will ensure that the stored password is compliant with the
requirement set in the configuration file. If not (the length of the
salt or the number of iterations is not correct, the password is
rehashed and updated in the database).

This update should not impact the login process for old users.

When no marks are available for a donor, the blue question mark is used
instead of using the "ok" green tick.

This will allows the user to call the correct redis database based upon
a string name in a dict, and not a variable perse. The definition of the
databases is easier this way, and the call of the correct database is
clearer in code.

This will renew the save of the TOTP server side for the username/IP tuple.

This will not change the behavior of the verify() function but is easier
to read.

This commit will add a time waste function if the username is not
present in the database. This is done to prevent the data extraction, in
this case the presence or not, of a username based upon the execution
time for the login process.

In the configuration file, the 'fake_hash' variable is computed with the
input data "fake_data" and the salt "fake_salt" to be transparent about
the data used as input for the hashing function.

The comparison with the 'verify()' function is a boolean (always True in
this case), and is not used in any useful way in the login process.

This waste of time is done even if the risk factor is very small (not to
say inexistent).

The location of this function call is designed to be only present if the
username provided as input does not exists in the database. This is done
to not impact real users.

This will trigger a rate limitation when the username does not exists or
if the password is not the correct one. The time to wait is exponential
(base 2) after the 5 first attempts.