2

У меня есть приложение с открытым доступом, использующее Firebase, с анонимным auth. Пользовательские данные используются для создания точек на карте. Каждый анонимный пользователь может редактировать данные только внутри узла, соответствующего их идентификатору auth, с помощью правил безопасности.Как обеспечить структуру базы данных Firebase с помощью анонимного auth?

Однако мое приложение зависит от конкретной структуры базы данных. Как обеспечить структуру/целостность базы данных с помощью анонимного auth, поскольку URL-адрес базы данных читается на стороне клиента?

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

Каждый узел auth может иметь много ключевых узлов, но я бы хотел ограничить эту сторону Firebase. И каждый ключевой узел должен следовать схеме ниже (так что я могу легко вытащить geojson). Ниже моя текущая настройка - интересно, чего не хватает?

"features" : { 
    "5AGxfaK2q8hjJsmsO3PUxUs09Sz1" : { 
     "-KS3R4sWPdcDkrxyIFX6" : { 
     "geometry" : { 
      "coordinates" : [ -81.88247680664062, 38.884619201291905 ], 
      "type" : "Point" 
     }, 
     "properties" : { 
      "color" : "#2be", 
      "title" : "" 
     }, 
     "type" : "Feature" 
     }, 

firebase rules

+0

Возможно, вы использовали компилятор болтов. Он позволяет определять типы и может упростить определение схемы с использованием правил безопасности. См. Https://github.com/firebase/bolt – cartant

+0

Вы включили изображение дерева JSON в свой вопрос. Пожалуйста, замените это на фактический JSON как текст, который вы легко можете получить, нажав кнопку «Экспорт» в консоли базы данных Firebase. Наличие JSON в качестве текста делает его доступным для поиска, позволяет нам легко использовать его для тестирования с вашими фактическими данными и использовать его в нашем ответе, и в целом это просто хорошая вещь. –

+0

Pic намного легче читать, но я могу включить фактические данные, конечно. Я скоро поправлюсь. – malcolm

ответ

1

аутентификации и схемы базы данных являются совершенно разные темы. Вы гарантируете схему базы данных, используя комбинацию из .write и .validate правил в своем документе безопасности, а не что-то связанное с вашим провайдером проверки подлинности (т. Е. Анонимная проверка подлинности).

Это подробно описано в нашем database security guide.

краткий обзор:

  • hasChildren: указать обязательные поля
  • newData: см записываемые данные
  • data: относятся к данным, уже в базе
  • .validate: указать схемы данных используя такие вещи, как newData.isString() или newData.val() == data.val() + 1

Имейте в виду, что правила .validate работают только для ненулевых значений. Таким образом, если вы хотите попробовать что-то вроде !data.exists() (т. Е. Вы можете писать только на этот путь один раз и не можете его модифицировать позже) или newData.exists() (т. Е. Вы не можете удалить эти данные), то вам нужно указать их в правиле .write ,

Подробнее см. В руководстве.

+0

Ну, если вы используете auth для входа в систему, то есть Oauth перенаправления доменов, но из старых документов firebase кажется, что анонимный auth не включен.Вы можете утверждать, что домен ssl может быть подделан, но, не считая этого, для случаев, когда используются домены перенаправления присяги, правила могут быть назначены на стороне клиента в javascript, правильно? – malcolm

+0

Правила безопасности управляются на сервере, а не на клиенте. – Kato

+0

Does hasChildren возвращает false, если у newData больше детей, чем указано? Или мне нужно использовать «$ other»: {".validate": "false"}, как описано выше? – malcolm