управление токенами APNS и FCM на сервере

Question

Я пытался выяснить, как управлять токенами APNS при регистрации устройства и на сервере уведомлений pu sh, который я пишу.

Суть проблемы связана с уникальной идентификацией устройство через деинсталляции и обновления приложений. Даже идентификатор поставщика может меняться при установке или обновлении. Кажется, что Apple и Google на самом деле не хотят, чтобы вы могли это сделать.

Похоже, есть некоторые обходные пути, такие как использование цепочки для ключей на iOS устройствах и внутреннее хранилище на Android, но из того, что я понимаю, по крайней мере один из этих методов требует разрешения пользователя, которое может отвергнуть некоторых пользователей. Я хочу уважать неприкосновенность частной жизни своих пользователей и укреплять доверие к ним.

Вот логика c, которую я до сих пор придумал:

1. store pu sh токены, которые будут однозначно идентифицироваться как application Id, platform, user Id и device Id (уникальное значение, сохраняемое приложением в localstorage) - этот уникальный идентификатор мы назовем APUD Id
2. , который мы будет иметь то, что по сути является конечной точкой upsert (насколько я обычно ненавижу upserts или действительно любую конечную точку generi c - кажется, это может быть хорошим случаем для исключения), которая принимает обновление токена или других данных устройства и определяет, существует ли соответствующее совпадение APUD Id - если это так, обновите эту строку, в противном случае создайте новый
3. При отправке уведомлений pu sh на устройство конкретного пользователя найдите все подходящие записи, которые еще не были удалены ( может быть, здесь трудно упростить удаление, чтобы избежать ошибок параллелизма, когда задействованы несколько экземпляров службы, но это OT - в идеале мы сохраняем эти данные хотя бы для некоторых период времени для поддержки и отладки). Поскольку мы не можем однозначно идентифицировать устройство, эти уведомления должны использовать соответствующий идентификатор свертывания (который должен позволять устройству однозначно идентифицировать уведомление), чтобы запретить пользователю получать дубликаты уведомлений.
4. Если Apple или Google отвечают с помощью указание на то, что токен истек / незарегистрирован, затем мягко удалите запись.

Вопросы:

1. Является ли шаг 4 надежным? Есть лучший способ сделать это? Есть ли способ проактивно управлять просроченными токенами с помощью задания cron? Приведет ли это просто к массовому накоплению токенов, срок действия которых редко истекает?
2. Есть ли вообще лучший или даже канонический способ приблизиться к этому?

Answer 1

Логика c выглядит хорошо. Это похоже (если не идентично) на подход, который я предлагал в нескольких моих ответах.

Является ли шаг 4 надежным? Есть лучший способ сделать это? Есть ли способ проактивно управлять просроченными токенами с помощью задания cron? Приведет ли это просто к массовому накоплению токенов, срок действия которых редко истекает?

Надежно до такой степени, что это должно предотвратить накопление токенов и предотвратить ненужные пу sh запросов.

Есть ли вообще лучший или даже канонический способ подойти к этому?

Мне еще предстоит найти лучше подход к обработке токенов FCM, кроме этого.

В зависимости от любых других характеристик, которые у вас есть (или могут скоро появиться), просто убедитесь (насколько это возможно:

• , что сопоставление токенов для каждого пользователя является точным (через onTokenRefresh())
• каждой платформы, для которых просрочены токены, удаляются (или архивируются, если необходимо, например, отладка)