If a sufficiently suspicious flurry of failed authentication events occurs (let's say 10 within a day for now), the associated user account should be put in a locked state. In order to unlock, the server owner (or anyone with access to the actual server instance), will need to invoke a CLI command to correct it.
Additional context
Create a new cli lib in crates that defines a clap interface. Refactor the server app to use this cli crate to either start the server or use a sub-command (e.g. unlock account).
In the container, I would envision the following possible:
# start the server
$ ./server
# unlock an account
$ ./server account lock --username <username>
# freeze an account
$ ./server account unlock --username <username>
# list all frozen accounts
$ ./server account list --locked
# reset password for a user
$ ./server account reset-password --username <username>
This would consume the core to query the DB directly
If a sufficiently suspicious flurry of failed authentication events occurs (let's say 10 within a day for now), the associated user account should be put in a locked state. In order to unlock, the server owner (or anyone with access to the actual server instance), will need to invoke a CLI command to correct it.
Additional context
Create a new
cli
lib incrates
that defines a clap interface. Refactor the server app to use thiscli
crate to either start the server or use a sub-command (e.g. unlock account).In the container, I would envision the following possible:
This would consume the
core
to query the DB directly