For a user to be able to be archived, each service that they are a
member of must have at least one other user who is active and who has
the 'manage-settings' permission.
To archive a user we remove them from all their services and
organisations, remove all permissions that they have and change some of
their details:
- email_address will start with '_archived_<date>'
- the current_session_id is changed (to sign them out of their current
session)
- mobile_number is removed (so we also need to switch their auth type to
email_auth)
- password is changed to a random password
- state is changed to 'inactive'
If any of the steps fail, we rollback all changes.
by hitting POST /<user_id>/email-code, we create an email two factor
code to send to the user. That email contains a link with a token that
will sign the user in when opened.
Also some other things:
"email verification" (aka when you first create an account) doesn't
hit the API anymore
refactor 2fa code verification and sending to use jsonschema, and share code between sms and email
Die marshmallow die!
until work is done to stop using PUT /user/{id} on the admin app, this
function also needs to reset failed logins, cos it's used during the
forgotten password flow
in verify_user_password, if succesful we reset the failed_login_count.
now we use failed_login_count for 2FA attempts, we need to make sure we
reset it in other places too, so that people don't get blocked,
especially in the reset-password user journey.
* verify_user_code - if it's succesful, reset the failed_login_count
* update_password - reset failed_login_count because either
* you're logged in and so it's 0 anyway
* you're resetting your password via pword reset link, and the old
count isn't relevant anymore
When the verify code is wrong or expired increment the failed to login count for the user.
When the verify code is successfully used reset the failed login count to 0.
