При выполнении маршрутизации на основе ролей в реагирует ли проблема безопасности с использованием оператора switch и отображения различных компонентов на основе ролей?

Question

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

<Route path={"/"} component={RootPage}></Route>

export default const RootPage({role}) => {
    switch(role) {
        case USER: return <MainPageUser />
        case ADMIN: return <AdminPage />
        default: return <MainPage />
    }
}

Answer 1

Есть несколько вариантов, которые вы можете выбрать, все они (почти) так же (небезопасны), как и другие. Это javascript, если кто-то хочет, то может изменить его на стороне клиента.

Вы можете сделать переключение, как вы делаете, или что-то вроде:

{role==="admin" && <AdminStuff />} // the component only gets rendered if the first part is true
{role==="user"  && <UserStuff />}  // so in this case it's one or the other.

Вы также можете создать компонент, который называется избирателем:

function RoleVoter({grantedRole, requiredRole, children){
    render(){
        return grantedRole===requiredRole ? children : null;
    }
}
// Example:
<RoleVoter grantedRole={role} requiredRole={ADMIN}> <AdminStuff/> </RoleVoter>

Каждый из них отличается по сложности и удобству использования, все они имеют свои преимущества / недостатки. Переключатель полезен, если «может совпадать только один случай». Метод && хорош для быстрого кодирования, но очень быстро приводит к жесткому кодированию, которое трудно поддерживать. Подход RoleVoter более сложный и может быть излишним, но теперь вы можете добавить туда любую роль, какую захотите. И разверните его, чтобы понимать несколько ролей (например, ADMIN и VIEW_ORDERS, если вам нужен такой уровень безопасности).

---

Все они примерно так же безопасны, как и другие. Это Javascript, на стороне клиента, ничего с этим не поделаешь. Более важно то, что вы выбираете решение, которое легко внедрить / понять разработчикам. Причина этого в том, что чем проще внедрить систему безопасности, тем чаще вы будете ее внедрять.

Тогда где же настоящая безопасность? Легко: на стороне сервера. Представьте, что вы взломали некоторый javascript и получили его, чтобы показать вам страницу администратора, но сервер так и не предоставил фактическое содержимое. Довольно бесполезно. Вы также создаете проверку безопасности на стороне сервера на основе текущего пользователя.

Несколько стандартный метод состоит в том, что вы заставляете избирателей (маленькие функции) проверять две вещи:

• Может ли пользователь добавлять / просматривать / редактировать / удалять этот тип элемента (в целом)? Например. имеет ли пользователь разрешение EDIT_USER при попытке редактировать пользователя? Или VIEW_ORDER при попытке просмотра заказа?
• Может ли пользователь добавлять / просматривать / редактировать / удалять этот конкретный элемент ? Например. если вы можете изменить заказ только тогда, когда он ваш, действительно ли он ваш?