Какой должен быть подход для хранения общедоступных данных? - PullRequest
0 голосов
/ 11 ноября 2019

У меня есть коллекция user-profile. В настоящее время он доступен для записи только пользователю, чей профиль.

Теперь я хочу записать количество посещений профиля, скажем, profileVisitedCount. И это также подсчитывает, если не подписанный пользователь посещает профиль.

Если я сохраню счет в документах самой коллекции user-profile из клиентской библиотеки firebase js, мне придется сделать ее общедоступной для записи.

Другой вариант, который я думаю, - использовать облачную функцию. Это только увеличит profileVisitedCount без необходимости делать документ общедоступным для записи. Но не уверен, что это правильный подход, поскольку конечная точка облачной функции все еще уязвима и может вызываться ботом.

Кроме того, данные типа «счетчик посещений профиля» должны записываться в аналитике, такой как GAно мне нужно, чтобы этот счетчик использовался в одной из бизнес-логик, таких как отображение самых посещаемых профилей.

Итак, есть ли какое-либо руководство по структурированию данных? Спасибо!

1 Ответ

0 голосов
/ 11 ноября 2019

У вас может быть другая коллекция с именем, например, profileVisitsCounters, в которой вы сохраняете один документ на пользователя с идентификатором документа, соответствующим идентификатору пользователя. В этом пользовательском документе вы поддерживаете выделенное поле profileVisitedCount, которое вы обновляете с помощью increment() каждый раз, когда пользователь читает соответствующий профиль.

Вы назначаете полный доступ на чтение и запись к этомуколлекция с allow read, write: if true;.


В своем вопросе, упоминая решение облачной функции, вы пишете, что «конечная точка облачной функции кажется уязвимой и может быть вызвана ботом». Помните, что в случае дополнительной коллекции с полным доступом для записи, как подробно описано выше, это также будет иметь место: например, кто-то, кто знает имя коллекции и пользовательские идентификаторы (ы), может вызвать метод update()JavaScript SDK или, что еще проще, конечная точка Cloud Firestore API .


Если вы хотите избежать этого риска, вы можете использовать вызываемую облачную функцию для чтения профилей пользователей, как вы упомянули. Эта облачная функция будет:

  1. извлекать данные профиля пользователя;
  2. увеличивать поле profileVisitedCount (в документе профиля пользователя);
  3. отправлять обратно пользователяДанные профиля для клиента.

Вам необходимо отказать в праве доступа на чтение к коллекции user-profile, чтобы заставить пользователей «читать» ее через облачную функцию.

Таким образом, вы уверены, что profileVisitedCount поля увеличиваются только при наличии «реального» профиля пользователя, считанного .

Обратите внимание, что вы все еще можете сохранить коллекцию profileVisitsCounters, если наличие двух разных коллекций принесет дополнительные преимущества для вашего бизнеса. В этом случае облачная функция будет увеличивать счетчик в этой коллекции вместо увеличения его в самом профиле пользователя. Вы бы ограничили право доступа к коллекции profileVisitsCounters только для чтения, поскольку облачная функция обходит правила безопасности. (allow read: if true; allow write: if false;).


Наконец, обратите внимание, что может быть интересно прочитать эту статью , в которой, среди прочего, подробно описаны плюсы и минусы запросов к базам данных Firebase с помощью CloudФункции.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...