2016-08-07 2 views
0

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

У меня проблема с authentication.i настроили аутентификацию для Google и электронной почты плюс пароль.

моя цель - разрешить любому пользователю читать данные, но только один пользователь (я) может записывать данные после входа в систему, используя один адрес электронной почты и пароль.

я могу успешно читать и писать в базу данных, если я войти в систему с помощью Google (с правилами установлен: AUTH = нуль.)

я также может читать и записывать в базу данных, используя те же правила (auth! = null), если я вхожу в систему с адресом электронной почты и паролем.

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

Я попытался включить пользовательский узел в правила, но я не могу получить доступ при использовании симулятора (см. Ниже), и я не знаю, как включить uid (который я могу получить после входа в систему), когда строительство ссылки - это ссылки я в настоящее время использую (который работает с чтением и записью правила, установленное к истине):

DatabaseReference databaseReference = mRootReference.child("Action_helper/1/Action_table_of_contents"); 

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

здесь является расположение моих данных:

enter image description here

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

Auth { "поставщик": "firebase", "UID": "Rp3OgoaABMN3hqTv0aF29ECQRCQ2"}

примечания: я получаю поставщик и идентификатор пользователя из Firebase объект после входа в систему с помощью адреса электронной почты и пароль, который я настроил аутентификации Firebase:

FirebaseUser user = FirebaseAuth.getInstance().getCurrentUser(); 
    if (user != null) { 
     // User is signed in 
     userId = user.getUid(); 
     String provider = user.getProviderId(); 

enter image description here

enter image description here

Я был бы признателен за помощь в 1) формулировании моих правил, 2) если и как я должен изменить свою структуру данных, и, наконец, 3) как включить uid в ссылку базы данных, которую я буду использовать для записи данных в база данных.

благодаря

ответ

1

Там нет пользователей узла так, определяя в правилах не помогло бы. Я думаю, что правило, которое может работать будет что-то вроде ниже (предполагается, 0 и 1 являются UID):

{ 
     "rules": { 

     "Action_helper":{ 

      "$uid":{ 

       //user-based security 
       ".read": "auth != null && $uid === auth.uid", 
       ".write": "auth != null", 

      }//$uid 

     }//Action_helper 

    }// rules 
} 

экспертизы выше правила по умолчанию, если не определить правила, то оно ложно т.е. на Action_helper ложно для как чтение, так и запись.Когда дело доходит до узла uid (где $ обозначает wild card), тогда мы проверяем, является ли идентификатор пользователя зарегистрированного пользователя одинаковым для uid этого узла и соответственно определяет правила.

Я очень рекомендую идти по ссылке The key to Firebase security - Google I/O 2016, это очень полезно, легко следовать, и лучше всего объяснение, которое я нашел до сих пор с демонстрационным примером.

Структура данных будет зависеть от ваших требований и экранов. Хотя Firebase позволяет 32 уровня вложенности, настоятельно рекомендуется вставлять узлы как можно меньше. И еще одна важная вещь, которая должна думать о компоновке данных, заключается в том, чтобы сохранить данные как можно денормализованные, даже если мы должны сделать копии полей по узлам.

Чтобы включить идентификатор пользователя в ссылке базы данных вы можете держать на добавление каждого ребенка:

DatabaseReference databaseReference = mRootReference.child("Action_helper).child(uid).child("Action_table_of_contents"); 

Таким образом, здесь мы имеем в виду от корневого узла к ребенку «Action_helper» и идти дальше вниз, это ребенок, который соответствует UID и из этого uid мы ссылаемся на ребенка «Action_table_of_contents».

0

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

enter image description here

и вот мои правила:

enter image description here

по существу она работает в тренажере, но в коде, я могу войти и читать и писать. НО у меня теперь есть проблема, если я не вхожу в систему, тогда uid, переданный в ссылке запроса, является нулевым, если я помещаю фиктивное значение в качестве uid, то я вообще не могу получить доступ к данным (поскольку данные находятся под users/the_valid_uid, а фиктивный uid не соответствует the_valid_uid).

так как я могу создать ссылку на базу данных без жесткого кодирования действительного пользовательского uid? так что я могу получить доступ к данным в узлах Addiction_items и table_of_contents_items (моя цель - разрешить кому-либо читать данные в обоих узлах, но разрешить одному пользователю (самому себе) иметь возможность писать на оба узла после входа в систему с моим адресом электронной почты ? и пароль

благодаря

+0

Попробуйте переместить «.read„:“правда», к началу узла т.е. поместить его прямо под „правила“:. узел Это позволит любому прочитать от корневого узла до всех других дочернего узла и нет необходимости в проверке подлинности. – 0p3n5ourcE

+0

И для его тестирования вы можете попробовать в симуляторе с проверкой подлинности и попробовать прочитать любой узел. – 0p3n5ourcE

+0

благодарит @openSource за вашу помощь и ссылку на рекомендацию youtube firebase. Я наконец получил его работу по назначению. Я включил && $ uid === 'my email login uid' в правилах написания, чтобы только электронный адрес электронной почты мог записываться в папку пользователя (иначе любой пользователь мог бы написать там). –