Можно ли построить скрытые области / React-компоненты на основе данных на стороне сервера? - PullRequest
Новая
       12

Можно ли построить скрытые области / React-компоненты на основе данных на стороне сервера?

1 голос
/ 26 июня 2019

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

Итак, скажем, у нас есть разные группы пользователей (скажем, a, b и c), которые могут обрабатывать разные страницы и разные компоненты страницы.Может пользователь А является полноценным администратором, который может видеть все страницы и компоненты на страницах.Пользователь b имеет доступ только к страницам и компонентам подраздела в проекте.Пользователь c может быть пользователем «только для чтения».

Права пользователя хранятся в базе данных, которая использовалась в jsf ранее.Мы хотим перейти на «2019» вместо сохранения «технологии 2010».В JSF мы хранили информацию о разрешениях пользователей в Session-Scoped bean-компонентах и ​​затем строили страницы, в которых были компоненты, которые мы могли бы отображать или нет (например, <button render=#{user.isallowedto}>).

Возможно ли сделать то же самое вотреагировать приложение с бэкэндом узла?Выполнение процесса входа с обработкой разрешений в бэкэнде узла с использованием экспресс-сессии и паспорта уже прошло успешно, но может ли информация о разрешениях пользователя также использоваться в нашем интерфейсе реакции?

Любая помощь была бы полезной!Большое спасибо!

1 Ответ

0 голосов
/ 26 июня 2019

внешняя защита против внутренней защиты

* 1003 интерфейс * Таким образом, на базовом уровне вы можете защитить интерфейс приложения, имея что-то вроде этого import React from 'react'; export function button ({text, action, isAdmin}) { if (!isAdmin) return null; return <button onClick={(e) => action(e)}>{text}</button> } , где isAdmin - это то, что вы определяете в сеансе или входите в систему с помощью пользовательского списка. Ваш клиент для входа должен предоставить эту информацию с помощью токена или объекта пользователя. В приведенном выше примере мы возвращаем null, когда нет пользователя-администратора, null является допустимым возвращением для реагирующего компонента, он просто ничего не отображает. бэкенд

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

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

заключение

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

...