Защита базы данных Firebase Realtime с сохранением оптимизаций - PullRequest
Новая
       0

Защита базы данных Firebase Realtime с сохранением оптимизаций

0 голосов
/ 24 февраля 2020

Как можно защитить структуру, если входные данные представляют собой объект json, состоящий из нескольких объектов json с непредопределенными уникальными ключами на родительский узел (например, на пользователя)?

То же самое вопрос с примером:

  • Любой пользователь может иметь любимую еду.
  • Подробная информация о еде не важна, так как эта информация поступает откуда-то еще.
  • Пользователь может иметь больше -1 и меньше 1001 количества любимых продуктов.
  • Синхронизировать нужно только измененные данные, чтобы минимизировать затраты Firebase.

Итак, если пользователь отметил 3 продукты с id E5435, 59z195J, k311 в качестве избранных: следующая структура кажется в порядке. 

{ fav: { $uid { "E5435":1, "59z195J":1, "k311":1 } } }

Но! Как можно предотвратить расширение структуры с произвольными данными? Вы можете добавить правила проверки для проверки типа и длины данных и т. Д. c .. но дочерние имена не определены и могут быть чем-то похожим на приведенный выше пример.

Я не хочу сохранять 1 длинную строку избранного, поскольку это означает syn c не будет работать частично, и я должен перезаписывать данные и загружать каждый раз.

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

Как можно добавить правило для защиты этой структуры, когда возможный ввод выглядит примерно так: 

/fav/UID1234567/ <-- {"AAAA5":1,"G545345":1,"D454WW":1}

( Примечания: Идентификаторы продуктов питания намеренно написаны со смешанными символов. Если это облегчает анализ вопроса, их можно заменить именами.

AAAA5 --> APPLE, D454WW --> RICE ), формируя: /fav/UID1234567/ <-- {"APPLE":1,"RICE":1}

И имейте в виду, что не может быть заранее заданного списка продуктов на выбор: Итак, ничего вроде [BANANA, APPLE, RICE, SUSHI,.....] не существует. Этот ОГРОМНЫЙ список существует, но за пределами Firebase.

Когда клиент полностью загружает содержимое /fav/USERID/ (o только один раз), он сравнивает весь список с каким-либо другим списком, чтобы отфильтровать эти элементы и показать их как избранные.

Конец заметок )

Дополнительная информация: Для ясности, как бы вы запретили использование какого-либо длинного текста вместо «APPLE» и снова длинного текста вместо значения «1». Поскольку эти данные увеличат стоимость базы и могут рассматриваться как атаки. Обычные правила проверки, похоже, не работают, так как в этом примере мы не выдвигаем значения 1 на 1, а их несколько. Итак, нет newData().children().key.isString() и newData().children().key.length(), et c ...

1 Ответ

1 голос
/ 24 февраля 2020

Итак, если вы хотите ограничить длину идентификаторов узлов любимой еды, а также установить значение для такого узла равным 1, то сработают следующие правила: 

{
  "rules": {
    "fav": {
      "$uid": {
        "$foodid": {
          ".read": true,
          ".write": true,
          ".validate": "newData.isNumber() && newData.val() == 1 && $foodid.length < 5"
        }
      }
    }
  }
}

Обратите внимание, что это правило будет отлично работать для проталкивания только одного узла или нескольких узлов.

Вы можете попробовать следующее с JS SDK: 

var database = firebase.database();

var updates = {};
updates['fav/user456/AAA5'] = 1;
updates['fav/user456/ABVD'] = 1;
updates['fav/user123/YUIH'] = 1;

database.ref().update(updates);

Также обратите внимание, что вам, вероятно, нужно добавить деталь для проверки подлинности пользователя и выполнить запись в его / ее собственный родительский узел, например ".write": "$uid === auth.uid".

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

  1. Извлечь список продуктов (список «ОГРОМНЫЙ») через REST API, который вы бы открыли для сервера, читающего вашу sqlite DB;
  2. Убедитесь, что узел нового фаворита находится в списке.

Конечно, если список действительно ОГРОМНЫЙ, он может оказаться неэффективным с точки зрения затрат ... просто идея.

Прочтите эту статью для более подробной информации об этом подходе.

...