2016-02-23 12:47:48 +00:00
|
|
|
from notifications_python_client.errors import HTTPError
|
2016-01-19 15:50:31 +00:00
|
|
|
|
2021-07-22 14:05:11 +01:00
|
|
|
from app.notify_client import NotifyAdminAPIClient, cache
|
|
|
|
|
from app.utils.user_permissions import (
|
2018-02-28 15:37:49 +00:00
|
|
|
translate_permissions_from_admin_roles_to_db,
|
|
|
|
|
)
|
2016-01-28 15:34:02 +00:00
|
|
|
|
2016-11-09 15:06:02 +00:00
|
|
|
ALLOWED_ATTRIBUTES = {
|
|
|
|
|
'name',
|
|
|
|
|
'email_address',
|
2017-11-01 15:36:27 +00:00
|
|
|
'mobile_number',
|
|
|
|
|
'auth_type',
|
2020-01-31 15:50:55 +00:00
|
|
|
'updated_by',
|
|
|
|
|
'current_session_id'
|
2016-11-09 15:06:02 +00:00
|
|
|
}
|
|
|
|
|
|
2016-01-19 15:50:31 +00:00
|
|
|
|
2016-11-30 17:01:44 +00:00
|
|
|
class UserApiClient(NotifyAdminAPIClient):
|
2016-01-19 22:47:42 +00:00
|
|
|
|
|
|
|
|
def init_app(self, app):
|
2018-02-09 15:03:32 +00:00
|
|
|
super().init_app(app)
|
2018-02-09 15:01:20 +00:00
|
|
|
self.admin_url = app.config['ADMIN_BASE_URL']
|
2016-01-19 15:50:31 +00:00
|
|
|
|
2017-11-13 13:39:31 +00:00
|
|
|
def register_user(self, name, email_address, mobile_number, password, auth_type):
|
2016-01-19 15:50:31 +00:00
|
|
|
data = {
|
|
|
|
|
"name": name,
|
|
|
|
|
"email_address": email_address,
|
|
|
|
|
"mobile_number": mobile_number,
|
2017-11-13 13:39:31 +00:00
|
|
|
"password": password,
|
|
|
|
|
"auth_type": auth_type
|
2016-01-19 22:47:42 +00:00
|
|
|
}
|
|
|
|
|
user_data = self.post("/user", data)
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
return user_data['data']
|
2016-01-19 22:47:42 +00:00
|
|
|
|
Cache `GET /user` response in Redis
In the same way, and for the same reasons that we’re caching the service
object.
Here’s a sample of the data returned by the API – so we should make sure
that any changes to this data invalidate the cache.
If we ever change a user’s phone number (for example) directly in the
database, then we will need to invalidate this cache manually.
```python
{
'data':{
'organisations':[
'4c707b81-4c6d-4d33-9376-17f0de6e0405'
],
'logged_in_at':'2018-04-10T11:41:03.781990Z',
'id':'2c45486e-177e-40b8-997d-5f4f81a461ca',
'email_address':'test@example.gov.uk',
'platform_admin':False,
'password_changed_at':'2018-01-01 10:10:10.100000',
'permissions':{
'42a9d4f2-1444-4e22-9133-52d9e406213f':[
'manage_api_keys',
'send_letters',
'manage_users',
'manage_templates',
'view_activity',
'send_texts',
'send_emails',
'manage_settings'
],
'a928eef8-0f25-41ca-b480-0447f29b2c20':[
'manage_users',
'manage_templates',
'manage_settings',
'send_texts',
'send_emails',
'send_letters',
'manage_api_keys',
'view_activity'
],
},
'state':'active',
'mobile_number':'07700900123',
'failed_login_count':0,
'name':'Example',
'services':[
'6078a8c0-52f5-4c4f-b724-d7d1ff2d3884',
'6afe3c1c-7fda-4d8d-aa8d-769c4bdf7803',
],
'current_session_id':'fea2ade1-db0a-4c90-93e7-c64a877ce83e',
'auth_type':'sms_auth'
}
}
```
2018-04-10 13:30:52 +01:00
|
|
|
def get_user(self, user_id):
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
return self._get_user(user_id)['data']
|
Cache `GET /user` response in Redis
In the same way, and for the same reasons that we’re caching the service
object.
Here’s a sample of the data returned by the API – so we should make sure
that any changes to this data invalidate the cache.
If we ever change a user’s phone number (for example) directly in the
database, then we will need to invalidate this cache manually.
```python
{
'data':{
'organisations':[
'4c707b81-4c6d-4d33-9376-17f0de6e0405'
],
'logged_in_at':'2018-04-10T11:41:03.781990Z',
'id':'2c45486e-177e-40b8-997d-5f4f81a461ca',
'email_address':'test@example.gov.uk',
'platform_admin':False,
'password_changed_at':'2018-01-01 10:10:10.100000',
'permissions':{
'42a9d4f2-1444-4e22-9133-52d9e406213f':[
'manage_api_keys',
'send_letters',
'manage_users',
'manage_templates',
'view_activity',
'send_texts',
'send_emails',
'manage_settings'
],
'a928eef8-0f25-41ca-b480-0447f29b2c20':[
'manage_users',
'manage_templates',
'manage_settings',
'send_texts',
'send_emails',
'send_letters',
'manage_api_keys',
'view_activity'
],
},
'state':'active',
'mobile_number':'07700900123',
'failed_login_count':0,
'name':'Example',
'services':[
'6078a8c0-52f5-4c4f-b724-d7d1ff2d3884',
'6afe3c1c-7fda-4d8d-aa8d-769c4bdf7803',
],
'current_session_id':'fea2ade1-db0a-4c90-93e7-c64a877ce83e',
'auth_type':'sms_auth'
}
}
```
2018-04-10 13:30:52 +01:00
|
|
|
|
2018-04-20 16:32:02 +01:00
|
|
|
@cache.set('user-{user_id}')
|
Cache `GET /user` response in Redis
In the same way, and for the same reasons that we’re caching the service
object.
Here’s a sample of the data returned by the API – so we should make sure
that any changes to this data invalidate the cache.
If we ever change a user’s phone number (for example) directly in the
database, then we will need to invalidate this cache manually.
```python
{
'data':{
'organisations':[
'4c707b81-4c6d-4d33-9376-17f0de6e0405'
],
'logged_in_at':'2018-04-10T11:41:03.781990Z',
'id':'2c45486e-177e-40b8-997d-5f4f81a461ca',
'email_address':'test@example.gov.uk',
'platform_admin':False,
'password_changed_at':'2018-01-01 10:10:10.100000',
'permissions':{
'42a9d4f2-1444-4e22-9133-52d9e406213f':[
'manage_api_keys',
'send_letters',
'manage_users',
'manage_templates',
'view_activity',
'send_texts',
'send_emails',
'manage_settings'
],
'a928eef8-0f25-41ca-b480-0447f29b2c20':[
'manage_users',
'manage_templates',
'manage_settings',
'send_texts',
'send_emails',
'send_letters',
'manage_api_keys',
'view_activity'
],
},
'state':'active',
'mobile_number':'07700900123',
'failed_login_count':0,
'name':'Example',
'services':[
'6078a8c0-52f5-4c4f-b724-d7d1ff2d3884',
'6afe3c1c-7fda-4d8d-aa8d-769c4bdf7803',
],
'current_session_id':'fea2ade1-db0a-4c90-93e7-c64a877ce83e',
'auth_type':'sms_auth'
}
}
```
2018-04-10 13:30:52 +01:00
|
|
|
def _get_user(self, user_id):
|
|
|
|
|
return self.get("/user/{}".format(user_id))
|
2016-01-20 15:13:15 +00:00
|
|
|
|
2016-02-23 12:47:48 +00:00
|
|
|
def get_user_by_email(self, email_address):
|
2021-03-05 15:05:48 +00:00
|
|
|
user_data = self.post('/user/email', data={'email': email_address})
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
return user_data['data']
|
2016-02-23 12:47:48 +00:00
|
|
|
|
2016-03-21 11:48:16 +00:00
|
|
|
def get_user_by_email_or_none(self, email_address):
|
|
|
|
|
try:
|
|
|
|
|
return self.get_user_by_email(email_address)
|
|
|
|
|
except HTTPError as e:
|
2016-04-29 09:38:59 +01:00
|
|
|
if e.status_code == 404:
|
2016-03-21 11:48:16 +00:00
|
|
|
return None
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
raise e
|
2016-01-21 11:33:53 +00:00
|
|
|
|
2018-04-20 16:32:02 +01:00
|
|
|
@cache.delete('user-{user_id}')
|
2016-11-09 15:06:02 +00:00
|
|
|
def update_user_attribute(self, user_id, **kwargs):
|
|
|
|
|
data = dict(kwargs)
|
|
|
|
|
disallowed_attributes = set(data.keys()) - ALLOWED_ATTRIBUTES
|
|
|
|
|
if disallowed_attributes:
|
|
|
|
|
raise TypeError('Not allowed to update user attributes: {}'.format(
|
|
|
|
|
", ".join(disallowed_attributes)
|
|
|
|
|
))
|
|
|
|
|
|
2016-11-10 12:10:01 +00:00
|
|
|
url = "/user/{}".format(user_id)
|
|
|
|
|
user_data = self.post(url, data=data)
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
return user_data['data']
|
2016-01-20 15:13:15 +00:00
|
|
|
|
2019-05-22 11:38:47 +01:00
|
|
|
@cache.delete('user-{user_id}')
|
|
|
|
|
def archive_user(self, user_id):
|
|
|
|
|
return self.post('/user/{}/archive'.format(user_id), data=None)
|
|
|
|
|
|
2018-04-20 16:32:02 +01:00
|
|
|
@cache.delete('user-{user_id}')
|
2017-02-28 14:41:31 +00:00
|
|
|
def reset_failed_login_count(self, user_id):
|
|
|
|
|
url = "/user/{}/reset-failed-login-count".format(user_id)
|
|
|
|
|
user_data = self.post(url, data={})
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
return user_data['data']
|
2017-02-28 14:41:31 +00:00
|
|
|
|
2018-04-20 16:32:02 +01:00
|
|
|
@cache.delete('user-{user_id}')
|
2020-02-18 14:28:03 +00:00
|
|
|
def update_password(self, user_id, password, validated_email_access=False):
|
2017-02-07 13:31:46 +00:00
|
|
|
data = {"_password": password}
|
2020-02-18 14:28:03 +00:00
|
|
|
if validated_email_access:
|
|
|
|
|
data["validated_email_access"] = validated_email_access
|
2017-02-07 13:31:46 +00:00
|
|
|
url = "/user/{}/update-password".format(user_id)
|
|
|
|
|
user_data = self.post(url, data=data)
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
return user_data['data']
|
2017-02-07 13:31:46 +00:00
|
|
|
|
2018-04-20 16:32:02 +01:00
|
|
|
@cache.delete('user-{user_id}')
|
2016-01-27 17:26:22 +00:00
|
|
|
def verify_password(self, user_id, password):
|
2016-01-21 11:33:53 +00:00
|
|
|
try:
|
2016-01-27 17:26:22 +00:00
|
|
|
url = "/user/{}/verify/password".format(user_id)
|
|
|
|
|
data = {"password": password}
|
2016-01-27 17:13:56 +00:00
|
|
|
self.post(url, data=data)
|
|
|
|
|
return True
|
2016-01-21 11:33:53 +00:00
|
|
|
except HTTPError as e:
|
|
|
|
|
if e.status_code == 400 or e.status_code == 404:
|
|
|
|
|
return False
|
|
|
|
|
|
2017-11-07 16:11:31 +00:00
|
|
|
def send_verify_code(self, user_id, code_type, to, next_string=None):
|
2016-02-22 12:33:59 +00:00
|
|
|
data = {'to': to}
|
2017-11-07 16:11:31 +00:00
|
|
|
if next_string:
|
|
|
|
|
data['next'] = next_string
|
2018-02-09 15:01:20 +00:00
|
|
|
if code_type == 'email':
|
|
|
|
|
data['email_auth_link_host'] = self.admin_url
|
2016-02-19 16:08:44 +00:00
|
|
|
endpoint = '/user/{0}/{1}-code'.format(user_id, code_type)
|
2016-03-17 13:07:52 +00:00
|
|
|
self.post(endpoint, data=data)
|
|
|
|
|
|
|
|
|
|
def send_verify_email(self, user_id, to):
|
|
|
|
|
data = {'to': to}
|
|
|
|
|
endpoint = '/user/{0}/email-verification'.format(user_id)
|
|
|
|
|
self.post(endpoint, data=data)
|
2016-01-27 12:22:32 +00:00
|
|
|
|
2016-07-12 11:53:30 +01:00
|
|
|
def send_already_registered_email(self, user_id, to):
|
2016-07-08 11:00:23 +01:00
|
|
|
data = {'email': to}
|
|
|
|
|
endpoint = '/user/{0}/email-already-registered'.format(user_id)
|
|
|
|
|
self.post(endpoint, data=data)
|
|
|
|
|
|
2018-04-20 16:32:02 +01:00
|
|
|
@cache.delete('user-{user_id}')
|
2016-01-27 12:22:32 +00:00
|
|
|
def check_verify_code(self, user_id, code, code_type):
|
|
|
|
|
data = {'code_type': code_type, 'code': code}
|
|
|
|
|
endpoint = '/user/{}/verify/code'.format(user_id)
|
|
|
|
|
try:
|
2017-02-24 16:21:41 +00:00
|
|
|
self.post(endpoint, data=data)
|
2016-01-27 12:22:32 +00:00
|
|
|
return True, ''
|
|
|
|
|
except HTTPError as e:
|
|
|
|
|
if e.status_code == 400 or e.status_code == 404:
|
2019-01-15 16:32:26 +00:00
|
|
|
return False, e.message
|
2016-01-27 12:22:32 +00:00
|
|
|
raise e
|
|
|
|
|
|
2021-05-17 15:56:15 +01:00
|
|
|
@cache.delete('user-{user_id}')
|
2021-06-02 11:25:02 +01:00
|
|
|
def complete_webauthn_login_attempt(self, user_id, is_successful):
|
2021-05-17 15:56:15 +01:00
|
|
|
data = {'successful': is_successful}
|
2021-06-03 12:46:31 +01:00
|
|
|
endpoint = f'/user/{user_id}/complete/webauthn-login'
|
2021-05-17 15:56:15 +01:00
|
|
|
try:
|
|
|
|
|
self.post(endpoint, data=data)
|
|
|
|
|
return True, ''
|
|
|
|
|
except HTTPError as e:
|
|
|
|
|
if e.status_code == 403:
|
|
|
|
|
return False, e.message
|
|
|
|
|
raise e
|
|
|
|
|
|
2016-02-23 17:51:09 +00:00
|
|
|
def get_users_for_service(self, service_id):
|
|
|
|
|
endpoint = '/service/{}/users'.format(service_id)
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
return self.get(endpoint)['data']
|
2018-02-21 10:18:56 +00:00
|
|
|
|
2018-02-19 16:53:29 +00:00
|
|
|
def get_users_for_organisation(self, org_id):
|
|
|
|
|
endpoint = '/organisations/{}/users'.format(org_id)
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
return self.get(endpoint)['data']
|
2018-02-19 16:53:29 +00:00
|
|
|
|
2018-04-20 16:32:02 +01:00
|
|
|
@cache.delete('service-{service_id}')
|
2019-03-19 11:49:10 +00:00
|
|
|
@cache.delete('service-{service_id}-template-folders')
|
2018-04-20 16:32:02 +01:00
|
|
|
@cache.delete('user-{user_id}')
|
2019-03-15 14:57:39 +00:00
|
|
|
def add_user_to_service(self, service_id, user_id, permissions, folder_permissions):
|
2018-02-28 15:37:49 +00:00
|
|
|
# permissions passed in are the combined admin roles, not db permissions
|
2016-02-29 17:35:21 +00:00
|
|
|
endpoint = '/service/{}/users/{}'.format(service_id, user_id)
|
2019-03-12 16:54:48 +00:00
|
|
|
data = {
|
2019-03-15 14:57:39 +00:00
|
|
|
'permissions': [{'permission': x} for x in translate_permissions_from_admin_roles_to_db(permissions)],
|
|
|
|
|
'folder_permissions': folder_permissions,
|
2019-03-12 16:54:48 +00:00
|
|
|
}
|
|
|
|
|
|
2018-03-01 16:59:01 +00:00
|
|
|
self.post(endpoint, data=data)
|
2016-03-03 10:24:49 +00:00
|
|
|
|
2018-04-20 16:32:02 +01:00
|
|
|
@cache.delete('user-{user_id}')
|
2018-02-19 16:53:29 +00:00
|
|
|
def add_user_to_organisation(self, org_id, user_id):
|
|
|
|
|
resp = self.post('/organisations/{}/users/{}'.format(org_id, user_id), data={})
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
return resp['data']
|
2018-02-19 16:53:29 +00:00
|
|
|
|
2019-02-27 15:45:18 +00:00
|
|
|
@cache.delete('service-{service_id}-template-folders')
|
2018-04-20 16:32:02 +01:00
|
|
|
@cache.delete('user-{user_id}')
|
2019-02-27 15:45:18 +00:00
|
|
|
def set_user_permissions(self, user_id, service_id, permissions, folder_permissions=None):
|
2018-02-28 15:37:49 +00:00
|
|
|
# permissions passed in are the combined admin roles, not db permissions
|
2019-02-21 15:06:41 +00:00
|
|
|
data = {
|
2019-02-27 15:45:18 +00:00
|
|
|
'permissions': [{'permission': x} for x in translate_permissions_from_admin_roles_to_db(permissions)],
|
2019-02-21 15:06:41 +00:00
|
|
|
}
|
|
|
|
|
|
2019-02-27 15:45:18 +00:00
|
|
|
if folder_permissions is not None:
|
|
|
|
|
data['folder_permissions'] = folder_permissions
|
|
|
|
|
|
2016-03-03 10:24:49 +00:00
|
|
|
endpoint = '/user/{}/service/{}/permission'.format(user_id, service_id)
|
2016-03-07 18:18:52 +00:00
|
|
|
self.post(endpoint, data=data)
|
|
|
|
|
|
2020-10-05 15:51:44 +01:00
|
|
|
def send_reset_password_url(self, email_address, next_string=None):
|
2016-03-07 18:18:52 +00:00
|
|
|
endpoint = '/user/reset-password'
|
|
|
|
|
data = {'email': email_address}
|
2020-10-05 15:51:44 +01:00
|
|
|
if next_string:
|
|
|
|
|
data['next'] = next_string
|
2016-03-07 18:18:52 +00:00
|
|
|
self.post(endpoint, data=data)
|
2016-03-17 13:07:52 +00:00
|
|
|
|
2018-07-06 16:16:21 +01:00
|
|
|
def find_users_by_full_or_partial_email(self, email_address):
|
|
|
|
|
endpoint = '/user/find-users-by-email'
|
|
|
|
|
data = {'email': email_address}
|
|
|
|
|
users = self.post(endpoint, data=data)
|
|
|
|
|
return users
|
|
|
|
|
|
2018-04-20 16:32:02 +01:00
|
|
|
@cache.delete('user-{user_id}')
|
Make user API client return JSON, not a model
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
2019-05-23 15:27:35 +01:00
|
|
|
def activate_user(self, user_id):
|
Cache `GET /user` response in Redis
In the same way, and for the same reasons that we’re caching the service
object.
Here’s a sample of the data returned by the API – so we should make sure
that any changes to this data invalidate the cache.
If we ever change a user’s phone number (for example) directly in the
database, then we will need to invalidate this cache manually.
```python
{
'data':{
'organisations':[
'4c707b81-4c6d-4d33-9376-17f0de6e0405'
],
'logged_in_at':'2018-04-10T11:41:03.781990Z',
'id':'2c45486e-177e-40b8-997d-5f4f81a461ca',
'email_address':'test@example.gov.uk',
'platform_admin':False,
'password_changed_at':'2018-01-01 10:10:10.100000',
'permissions':{
'42a9d4f2-1444-4e22-9133-52d9e406213f':[
'manage_api_keys',
'send_letters',
'manage_users',
'manage_templates',
'view_activity',
'send_texts',
'send_emails',
'manage_settings'
],
'a928eef8-0f25-41ca-b480-0447f29b2c20':[
'manage_users',
'manage_templates',
'manage_settings',
'send_texts',
'send_emails',
'send_letters',
'manage_api_keys',
'view_activity'
],
},
'state':'active',
'mobile_number':'07700900123',
'failed_login_count':0,
'name':'Example',
'services':[
'6078a8c0-52f5-4c4f-b724-d7d1ff2d3884',
'6afe3c1c-7fda-4d8d-aa8d-769c4bdf7803',
],
'current_session_id':'fea2ade1-db0a-4c90-93e7-c64a877ce83e',
'auth_type':'sms_auth'
}
}
```
2018-04-10 13:30:52 +01:00
|
|
|
return self.post("/user/{}/activate".format(user_id), data=None)
|
|
|
|
|
|
2016-10-13 17:05:37 +01:00
|
|
|
def send_change_email_verification(self, user_id, new_email):
|
|
|
|
|
endpoint = '/user/{}/change-email-verification'.format(user_id)
|
|
|
|
|
data = {'email': new_email}
|
|
|
|
|
self.post(endpoint, data)
|
2018-03-07 18:10:14 +00:00
|
|
|
|
2019-06-07 09:26:11 +01:00
|
|
|
def get_organisations_and_services_for_user(self, user_id):
|
|
|
|
|
endpoint = '/user/{}/organisations-and-services'.format(user_id)
|
2018-03-07 18:10:14 +00:00
|
|
|
return self.get(endpoint)
|
2018-07-19 12:30:04 +01:00
|
|
|
|
2021-05-07 15:00:01 +01:00
|
|
|
def get_webauthn_credentials_for_user(self, user_id):
|
2021-05-13 15:54:05 +01:00
|
|
|
endpoint = f'/user/{user_id}/webauthn'
|
2021-05-07 15:00:01 +01:00
|
|
|
|
2021-05-13 15:54:05 +01:00
|
|
|
return self.get(endpoint)['data']
|
Support registering a new authenticator
This adds Yubico's FIDO2 library and two APIs for working with the
"navigator.credentials.create()" function in JavaScript. The GET
API uses the library to generate options for the "create()" function,
and the POST API decodes and verifies the resulting credential. While
the options and response are dict-like, CBOR is necessary to encode
some of the byte-level values, which can't be represented in JSON.
Much of the code here is based on the Yubico library example [1][2].
Implementation notes:
- There are definitely better ways to alert the user about failure, but
window.alert() will do for the time being. Using location.reload() is
also a bit jarring if the page scrolls, but not a major issue.
- Ideally we would use window.fetch() to do AJAX calls, but we don't
have a polyfill for this, and we use $.ajax() elsewhere [3]. We need
to do a few weird tricks [6] to stop jQuery trashing the data.
- The FIDO2 server doesn't serve web requests; it's just a "server" in
the sense of WebAuthn terminology. It lives in its own module, since it
needs to be initialised with the app / config.
- $.ajax returns a promise-like object. Although we've used ".fail()"
elsewhere [3], I couldn't find a stub object that supports it, so I've
gone for ".catch()", and used a Promise stub object in tests.
- WebAuthn only works over HTTPS, but there's an exception for "localhost"
[4]. However, the library is a bit too strict [5], so we have to disable
origin verification to avoid needing HTTPS for dev work.
[1]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/examples/server/server.py
[2]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/examples/server/static/register.html
[3]: https://github.com/alphagov/notifications-admin/blob/91453d36395b7a0cf2998dfb8a5f52cc9e96640f/app/assets/javascripts/updateContent.js#L33
[4]: https://stackoverflow.com/questions/55971593/navigator-credentials-is-null-on-local-server
[5]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/fido2/rpid.py#L69
[6]: https://stackoverflow.com/questions/12394622/does-jquery-ajax-or-load-allow-for-responsetype-arraybuffer
2021-05-07 18:10:07 +01:00
|
|
|
|
2021-05-13 15:54:05 +01:00
|
|
|
def create_webauthn_credential_for_user(self, user_id, credential):
|
|
|
|
|
endpoint = f'/user/{user_id}/webauthn'
|
Support registering a new authenticator
This adds Yubico's FIDO2 library and two APIs for working with the
"navigator.credentials.create()" function in JavaScript. The GET
API uses the library to generate options for the "create()" function,
and the POST API decodes and verifies the resulting credential. While
the options and response are dict-like, CBOR is necessary to encode
some of the byte-level values, which can't be represented in JSON.
Much of the code here is based on the Yubico library example [1][2].
Implementation notes:
- There are definitely better ways to alert the user about failure, but
window.alert() will do for the time being. Using location.reload() is
also a bit jarring if the page scrolls, but not a major issue.
- Ideally we would use window.fetch() to do AJAX calls, but we don't
have a polyfill for this, and we use $.ajax() elsewhere [3]. We need
to do a few weird tricks [6] to stop jQuery trashing the data.
- The FIDO2 server doesn't serve web requests; it's just a "server" in
the sense of WebAuthn terminology. It lives in its own module, since it
needs to be initialised with the app / config.
- $.ajax returns a promise-like object. Although we've used ".fail()"
elsewhere [3], I couldn't find a stub object that supports it, so I've
gone for ".catch()", and used a Promise stub object in tests.
- WebAuthn only works over HTTPS, but there's an exception for "localhost"
[4]. However, the library is a bit too strict [5], so we have to disable
origin verification to avoid needing HTTPS for dev work.
[1]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/examples/server/server.py
[2]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/examples/server/static/register.html
[3]: https://github.com/alphagov/notifications-admin/blob/91453d36395b7a0cf2998dfb8a5f52cc9e96640f/app/assets/javascripts/updateContent.js#L33
[4]: https://stackoverflow.com/questions/55971593/navigator-credentials-is-null-on-local-server
[5]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/fido2/rpid.py#L69
[6]: https://stackoverflow.com/questions/12394622/does-jquery-ajax-or-load-allow-for-responsetype-arraybuffer
2021-05-07 18:10:07 +01:00
|
|
|
|
2021-05-13 15:54:05 +01:00
|
|
|
return self.post(endpoint, data=credential.serialize())
|
Support registering a new authenticator
This adds Yubico's FIDO2 library and two APIs for working with the
"navigator.credentials.create()" function in JavaScript. The GET
API uses the library to generate options for the "create()" function,
and the POST API decodes and verifies the resulting credential. While
the options and response are dict-like, CBOR is necessary to encode
some of the byte-level values, which can't be represented in JSON.
Much of the code here is based on the Yubico library example [1][2].
Implementation notes:
- There are definitely better ways to alert the user about failure, but
window.alert() will do for the time being. Using location.reload() is
also a bit jarring if the page scrolls, but not a major issue.
- Ideally we would use window.fetch() to do AJAX calls, but we don't
have a polyfill for this, and we use $.ajax() elsewhere [3]. We need
to do a few weird tricks [6] to stop jQuery trashing the data.
- The FIDO2 server doesn't serve web requests; it's just a "server" in
the sense of WebAuthn terminology. It lives in its own module, since it
needs to be initialised with the app / config.
- $.ajax returns a promise-like object. Although we've used ".fail()"
elsewhere [3], I couldn't find a stub object that supports it, so I've
gone for ".catch()", and used a Promise stub object in tests.
- WebAuthn only works over HTTPS, but there's an exception for "localhost"
[4]. However, the library is a bit too strict [5], so we have to disable
origin verification to avoid needing HTTPS for dev work.
[1]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/examples/server/server.py
[2]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/examples/server/static/register.html
[3]: https://github.com/alphagov/notifications-admin/blob/91453d36395b7a0cf2998dfb8a5f52cc9e96640f/app/assets/javascripts/updateContent.js#L33
[4]: https://stackoverflow.com/questions/55971593/navigator-credentials-is-null-on-local-server
[5]: https://github.com/Yubico/python-fido2/blob/c42d9628a4f33d20c4401096fa8d3fc466d5b77f/fido2/rpid.py#L69
[6]: https://stackoverflow.com/questions/12394622/does-jquery-ajax-or-load-allow-for-responsetype-arraybuffer
2021-05-07 18:10:07 +01:00
|
|
|
|
2021-05-21 17:10:34 +01:00
|
|
|
def update_webauthn_credential_name_for_user(self, *, user_id, credential_id, new_name_for_credential):
|
2021-05-14 18:19:02 +01:00
|
|
|
endpoint = f'/user/{user_id}/webauthn/{credential_id}'
|
|
|
|
|
|
|
|
|
|
return self.post(endpoint, data={"name": new_name_for_credential})
|
|
|
|
|
|
2021-05-14 18:42:57 +01:00
|
|
|
def delete_webauthn_credential_for_user(self, *, user_id, credential_id):
|
|
|
|
|
endpoint = f'/user/{user_id}/webauthn/{credential_id}'
|
|
|
|
|
|
|
|
|
|
return self.delete(endpoint)
|
|
|
|
|
|
2018-10-26 15:39:32 +01:00
|
|
|
|
|
|
|
|
user_api_client = UserApiClient()
|