Enforce limit on number of devices per user

[gherceg]

Product Description

Technical Summary

https://dimagi.atlassian.net/browse/SAAS-16355

This returns a 403 if a user is attempting to restore from a new device id after exceeding the device limit. If they have used the device within the last 24 hours, they will be allowed to use it even if the device limit is exceeded.

The investigation done in this ticket highlighted that the distribution of device counts per user is mostly made up of 5 or below (taken from one random day):

1: 20301
2-5: 2624
6-10: 144
11-50: 74
Over 50: 4

It seems reasonable to set a very conservative device limit to start since the user experience when hitting this error isn't going to be great until the mobile team is able to handle this error specifically.

Feature Flag

Safety Assurance

Safety story

Automated test coverage

QA Plan

Rollback instructions

• This PR can be reverted after deploy with no further considerations

Labels & Review

• Risk label is set correctly
• The set of people pinged as reviewers is appropriate for the level of risk of the change

[snopoke]

Thanks for this @gherceg. Do you have a sense whether blocking the restore is the best option or whether we should also block any other endpoints like phone_keys or app_install? I think we can't block app install because it's unauthenticated right?

Is the logic for blocking sync that you really use a new device until you've done an initial sync?

[snopoke]

How about making this a setting to that it can be changed without a code deploy and 3rd parties can configure their own limits.

On the topic of 3rd parties, this change probably warrants a changelog entry.

[gherceg]

Yeah we had talked about potentially creating a new SQL model to update values like this quickly, but settings seems perfectly fine for now, and definitely better than a constant. Moved to settings in 93e48ec.

[gherceg]

And agreed on the changelog entry!

[millerdev]

Should this use utcnow() or whatever the acceptable equivalent is these days?

Aside: I find it annoying that utcnow() is deprecated. It's so easy to remember.

[gherceg]

Ah right. I believe it is now datetime.now(timezone.utc) based on these docs. See f90aa81

[snopoke]

In Django world you can also use django.utils.timezone.now()

[millerdev]

Can device ids be set by the submitting device? In other words, would it be possible for someone to make their mobile device(s) ids start with WebAppsLogin or be empty and exempt themselves from the limit? Do we care?

[gherceg]

Yeah good question that I do not know the answer to off the top of my head. I can dig more into this one and get back to you.

[snopoke]

The official CC Mobile app doesn't allow changing the device ID. Forms submitted by other means can set it to whatever they want. This makes me wonder if we need to account for API submitted forms (ignoring them)?

[gherceg]

Do you have a sense whether blocking the restore is the best option or whether we should also block any other endpoints like phone_keys or app_install? I think we can't block app install because it's unauthenticated right?

Is the logic for blocking sync that you really use a new device until you've done an initial sync?

I don't have a great sense of what the best option to enforce this is, and a large part of my reasoning here is simply because it is what I'm most familiar with. I'm definitely open to alternative approaches.

My logic was going off of the assumption that a restore is an inevitable part of both preparing a new device for use as well as existing devices syncing with the server. However, if my understanding is correct, this doesn't actually limit the number of devices that can submit forms against HQ from a specific user which seems like a fundamental issue.

Does it seem fair to say that what we really want to do is limit all mobile endpoints to X devices per user per day?

[snopoke]

Do you have a sense whether blocking the restore is the best option or whether we should also block any other endpoints like phone_keys or app_install? I think we can't block app install because it's unauthenticated right?
Is the logic for blocking sync that you really use a new device until you've done an initial sync?

I don't have a great sense of what the best option to enforce this is, and a large part of my reasoning here is simply because it is what I'm most familiar with. I'm definitely open to alternative approaches.

My logic was going off of the assumption that a restore is an inevitable part of both preparing a new device for use as well as existing devices syncing with the server. However, if my understanding is correct, this doesn't actually limit the number of devices that can submit forms against HQ from a specific user which seems like a fundamental issue.

Does it seem fair to say that what we really want to do is limit all mobile endpoints to X devices per user per day?

Keeping it at restores for now seems fine to me.