Ruby on rails + angular + devise - проблема безопасности нескольких ролей / моделей пользователей
Я создаю проект на ROR с интерфейсом Angular JS и серверной частью ROR API. Я начал с этого примера приложения: https://job-tracker-checklist.herokuapp.com/#/login
В пример приложения я добавил дополнительную модель пользователя (admin). Я смог показать другое меню для администраторов с помощью Angular JS:
<div ng-if = "signedInAsAdmin()" ng-include = "admin-nav.html"></div>
Это загружает меню, если администратор вошел в систему. Один из пунктов меню - указать admin.customers:
.state('admin.customers', {
url:'admin/customers',
templateUrl: 'admin/customers.html',
controller: 'CustomersController'
})
Это прекрасно работает. Однако это не блокирует доступ к странице только для администраторов. Любой может получить доступ к странице / admin / customers и отобразить этот шаблон (даже если на нем нет данных, потому что серверный API также проверяет аутентификацию).
Я вообще не хочу открывать этот экран, я бы предпочел перенаправить пользователя прямо на страницу входа в систему, если пользователь не авторизован.
Единственное известное мне решение для этого - проверить в javascript, аутентифицирован ли пользователь как администратор, а если нет, перенаправить пользователя. Согласно моим исследованиям, я могу сделать это с помощью события $ stateChangeStart в Angular. Поэтому перед изменением состояния проверьте аутентификацию и действуйте в соответствии с ее результатами.
Тем не менее, это безопасно? Я не эксперт в этом, но нельзя ли этим легко манипулировать, поскольку все это на стороне клиента?
Каков обычный и безопасный способ сделать это? Мне кажется, что полагаться только на Javascript с $ stateChangeStart небезопасно? Любая помощь, учебные пособия или информация будут очень признательны!
Обновлять
Я только что понял, что, по моему мнению, невозможно хранить шаблоны подальше от неавторизованных пользователей, что я считаю компромиссом при использовании клиентского фреймворка в качестве Angular js. Я имею в виду, что если кто-то проверит наши определения состояний, он сможет увидеть ссылку на файл шаблона и загрузить файл HTML. Поэтому для файлов шаблонов, специфичных для администратора, я не уверен, как с этим справиться. Я не хочу, чтобы наши пользователи могли видеть заголовки «примененная скидка клиента». Думаю, нет никакого способа обойти это? Единственный способ, который я могу себе представить, - это рендеринг важнейшего материала шаблона на стороне сервера (получить HTML-код из действия контроллера API, которое возвращает данные только в случае аутентификации). Я хотел бы услышать некоторые идеи по этому поводу!
Привет, Дэйв, большое спасибо за ответ. Так как же обычные приложения SPA, написанные на AngularJs, справляются с этим, когда им нужно иметь несколько ролей аутентификации? Я могу представить, что многие проекты не хотят, чтобы пользователи копались во всех специфичных для администратора шаблонах? Или это не совсем обычное дело - писать такое многопользовательское приложение только на Angular?
Количество ролей во многом не имеет значения. В конечном счете, именно данные должны быть защищены, а уровень представления, поскольку это в основном JS, редко актуален без связанных с ним данных (плюс сам DOM трудно получить самостоятельно). У меня лично нет проблем с людьми, обращающимися к маршрутам, которые бесполезны без их данных, но это только я: очень безопасное приложение, вероятно, просто будет использовать разные ресурсы JS и решать во время выполнения на основе auth / auth на стороне сервера, какие возвращаюсь к клиенту, но я только догадываюсь - извините!
Спасибо, Дэйв :) Я согласен, что с точки зрения безопасности все сводится к защите данных. Тем не менее, в нашем случае я бы предпочел сохранить частными административные шаблоны Angular. Мне нравится архитектура бэкэнда API с интерфейсом SPA, но я не могу вместить административный портал и портал для клиентов в один SPA, думаю, если я действительно хочу защитить административные шаблоны. Возможно, я создаю 2 разных SPA: 1 для администратора и 1 для пользователя в одном и том же API-интерфейсе ruby. Это даст мне немного больше свободы в обеспечении безопасности всего. Я собираюсь провести еще несколько исследований :) Еще раз спасибо!
В конечном итоге все, что вы можете сделать В самом деле, - это ограничить то, что серверная сторона отправляет; для SPA это почти всегда данные. Возможно, вы могли бы отправить другой пакет приложений, но, вероятно, это того не стоит.