Как реализовать контроль доступа в React, если пользователи могут изменять состояние

Question

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

<View>
    {!user && <LoginScreen />}
    {user && <WelcomeScreen user={user} />}
</View>

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

Может ли быть изменено состояние реакции для обхода мер безопасности?

Если пользователь может изменять состояние и просматривать компоненты, для которых у него нет разрешений, каков правильный способ обеспечения доступа на основе ролей? Хранение пользовательских данных как position: employee может быть изменено на position: manager на клиенте, и тогда они смогут видеть, какие опции доступны для менеджеров, даже если запросы REST не были сделаны.

В настоящее время я использую сеансовые куки для проверки пользовательской серверной части, и любые чувствительные к данным REST get / posts проходят проверку подлинности - но как это отразится на клиенте?

user logs in -> server verifies -> server sends back session variable that holds user.position / or sends json(user) -> client looks at session from server or json(user), stores user.position in state.user.position -> state.user.position is used in conditional if to determine whether or not to display components as above ---*but*---> client goes in and changes state state.user.position and gets access to components anyways

Если мы можем изменить состояние в клиенте, как мы можем безопасно использовать условные тесты в реакции / избыточности?

Answer 1

Нечто подобное обрабатывает серверная часть, а не React.Что бы вы ни делали, НЕ просто захватите все данные и отфильтруйте их в React.Я понятия не имею, как вы дифференцируете пользователей на основе вашего примера, но для простоты я предполагаю, что вы используете JWT .В этой реализации токен генерируется при входе в систему, и вы можете безопасно хранить его, например, в локальном хранилище или в резерве.Для всех вызовов API, которые вы делаете, вы должны прикрепить к ним токен.Затем сервер должен при каждом вызове, который выполняет зарегистрированный пользователь, делать несколько вещей:

• Проверка подписи токена
• Получение идентификатора пользователя из токена и получение разрешений /Роли
• Проверьте, имеет ли пользователь доступ к вызову API или нет

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

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

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

Редактировать: Обращаясь к комментарию

JWT просто предоставляет стандартизированный подход к проблеме.

Давайте на секунду предположим, что ваша переменная сеанса хранит следующую информацию {'userid': 5, 'position': manager}.Так что, если я хороший нападающий, я просто поменяю менеджера на администратора, посмотрим, где он меня получит, но если я не хороший, я попробую все идентификаторы пользователей от 0 до 10000, как с менеджером, так и с администратором какположение, посмотри, где это меня достает.Итак, вы попробуйте случайный идентификатор пользователя, например, хэш метки времени.Тем не менее, поверхность атаки только увеличилась.Теперь ты злишься на этих хакеров.Вы вроде как, я собираюсь зашифровать эту переменную сеанса, но я не могу на самом деле сохранить ключ в React, так как это можно взломать, я просто прикреплю зашифрованную вещь к каждому запросу, расшифрую, проверим,и утвердить, если это действительно.В этот момент вы практически заново изобрели JWT.