The admin app now needs to know a few extra things about orgs and
services in order to list them. At the moment it does this by making
multiple API calls.
This commit adds extra fields to the existing response. Once the admin
app is using this fields we’ll be able to remove:
- `reponse['services_without_organisations']`
- `reponse['organisations']['services']`
Updated the endpoint for `.set_permissions` to update a user's folder
permissions as well as permissions for a service. User folder
permissions are optional for now, since Admin is not currently passing
this data through.
The data posted to the `set_permissions` endpoint is currently sent as a
list of permissions:
`[{'permission': MANAGE_SETTINGS}, {'permission': MANAGE_TEMPLATES}]`.
This endpoint is going to also be used for folder permissions, so the
data now needs to be nested:
`{'permissions': [{'permission': MANAGE_SETTINGS}, {'permission': MANAGE_TEMPLATES}]}`
This changes the set_permissions endpoint to accept data in either
format. Once admin is sending data in the new format, the code can be
simplified.
contains orgs, and unmapped services.
the orgs contain nested services - services the user is a part of that
belong to that org.
the unmapped services are any services that the user is a part of that
either don't have an org or have one that the user doesn't know about
this is so that we can filter out inactive organisations and services
note: can't remove user schema completely, as we still use it in
POST /user to create new users
Similar to https://github.com/alphagov/notifications-api/pull/1515
This lets the admin app pass in a domain to use for email auth links,
so that when it’s running on a different URL users who try to sign in
will get an email auth link for the domain they sign in on, not the
default admin domain for the environment in which the API is running.
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!
There are three authentication methods:
- requires_no_auth - public endpoint that does not require an Authorisation header
- requires_auth - public endpoints that need an API key in the Authorisation header
- requires_admin_auth - private endpoint that requires an Authorisation header which contains the API key for the defined as the client admin user
when we change the last logged in time, set the current session id to
a random uuid
this way, we can compare it to the cookie a user has, and if they
differ then we can log them out
also update user.logged_in_at at 2FA rather than password check, since
that feels more accurate
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.
The reason for doing this is to ensure the tasks performed for the Notify users are not queued behind a large job, a way to
ensure priority for messages.
5th task for story: https://www.pivotaltracker.com/story/show/135839709
