Блог

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

Переходя непосредственно к моему вопросу, в настоящее время я разрабатываю базовое приложение HTML JS, в котором пользователь должен войти в систему, чтобы получить доступ к «частной» области; после входа в систему можно выполнять множество запросов на обслуживание и просматривать запросы других пользователей, являясь более или менее системой «интрасети».

Я использую Firebase Firestore в качестве базы данных и использую два подхода для взаимодействия с базой данных:

-Для управления аутентификацией пользователей (процессы входа и регистрации) я использую «интерфейсные» модули JS, предоставляемые Firebase, используя метод входа/пароля с активированной функцией подтверждения ссылки по электронной почте. После отправки запроса на аутентификацию приложение firebase возвращает токен, и на основе этого токена создается файл cookie сеанса, предоставляющий доступ к частной области. Таким образом, мне не нужно управлять большинством шагов проверки подлинности / учетной записи в моей внутренней части.

-Для любых других операций с базой данных (чтение и запись firestore) я использую SDK «firebase-admin» в сочетании с моей внутренней реализацией, таким образом, чтобы все запросы проверялись с помощью cookie сеанса перед фактическим выполнением. Серверная часть имеет доступ к «ключу» учетной записи службы JSON, который предоставляет ей полный доступ для чтения и записи ко всей базе данных.

Наконец, вопросы таковы:

-Является ли приемлемым или общепринятым использование обоих подходов, внешнего и внутреннего, для управления приложением firebase?

-После того, как все данные firestore управляются на внутренней стороне, и там управляются все правила чтения/записи/привилегий, правильно ли правильно устанавливать правила безопасности, чтобы блокировать все, как показано ниже? (учитывая, что firebase-администратор обходит все с внутренней стороны, не будучи затронутым)

 service cloud.firestore {  match /databases/{database}/documents {  match /{document=**} {  allow read, write: if false;  }  } }  

С наилучшими пожеланиями, и, пожалуйста, дайте мне знать, если я был ясен в своих сомнениях 🙂

Объединение внешнего и внутреннего кода при использовании Firestore (или других модулей Firebase) вполне нормально. Выполнение всего доступа к данным через SDK администратора (хотя это и не обязательно) также является полностью приемлемым подходом. Установка правил, запрещающих прямой доступ к SDK на стороне клиента (или с помощью маркеров идентификаторов через API REST), действительно является логичным шагом в этом сценарии.

Следует понимать, что теперь ваш код отвечает за то, чтобы все данные были авторизованы, в то время как в случаях, когда вы используете клиентские SDK Firebase, контроль доступа осуществляется правилами безопасности.