Как настроить REST авторизацию для AngulagJS и Yii2?

Question

[Антон Штинов]

Начал разрабатывать приложение. Бэкенд на Yii2, фронт энд с использованием angularjs. Так как только начала разбираться с этими фреймворками, то не особо понимаю какие нормальные решения уже есть. Примеров как использовать REST целая куча и все однотипны, а вот примеры авторизации мало и у каждого свой подход. Вот тут бы хотелось понять есть ли более менее стандартные решения, как со стороны фронта так и со стороны бэка?
И еще возник вопрос по поводу прав доступа, на стороне бэка просто - у пользователя будут права на определенные запросы. А вот какие есть стандартные методы работы с правами/ролями пользователя на фроненде? Основное не понимание как на фронте управлять видимостью различных областей. В какую сторону тут копать?

Comments

[Никита]

При чем здесь REST? Вы не туда копаете, там одним ajax запросом логин с паролем, а ответ токен какой-нибудь. Разграничением прав в Yii занимается RBAC.

Answer 1

[Сергей Протько]

и у каждого свой подход

Пожалуй это ключевая фраза. У каждого на самом деле свой подход. Кто-то делает авторизацию исключительно через Yii и потом аунтентификация проходит тупо по кукам, кто-то использует токены, кто-то JWT. Подходов масса.

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

У пользователя есть права. Это либо роль, либо список действий которые он может совершать. Словом все примерно как и на бэкэнде. Далее вы можете условия в шаблонах ставить или еще как. Для ангуляра есть несколько подходов организации ACL. В том числе готовых тоже много.

В какую сторону тут копать?

Фронтэнд не сильно отличается от бэкэнда. Вспомните как вы делали приложеньки с обычными формачками и т.д. Вот тоже самое, только теперь у вас нет "перезагрузки", то есть приложение живет пока открыта вкладка. Ну и в качестве базы данных у нас HTTP API какое-то. Вот и вся разница.

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

Comments

[Антон Штинов]

Отличный ответ, спасибо. Подскажите, что посмотреть для понимания подходов к ACL ангуляр?

[Сергей Протько]

Антон Штинов: я рекомендую вам вооружиться JWT. Готовые реализации есть и для PHP и для angular.

В токене сразу можно хранить какие-то права пользователя. А далее - ресолверы, которые будут запрещать грузить что не надо, а по поводу ACL - тут разные варианты. Хоть свои директивы, хоть какие-то отдельные модули. Тут конкретики подсказать не могу. Лучше поищите.

[copal]

Сергей Протько: меня самого тема с ролями интересует с недавних пор и Ваши слова ниже ввели в небольшой ступор.

Ну и все ограничения дублируются на бэкэнде в любом случае.

Я не буду спрашивать что вы имели ввиду под словом дублируется, а скажу как понимаю я.
А я понимаю так, что клиент рендерит только то, что ему отдает сервер. И если при полном рендере на сервере клиент не может отобразить того, что ему не отдаст сервер, то в случаи с spa клинт не может собрать того, чего нет в json присланного ему с сервера. То есть на клиенте ролей вообще нет, там только сборка компонентов по присланному json. Правильно я понимаю?

[Сергей Протько]

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

На UI вы тоже показываете только то что можно (ибо UX хороший надо), но даже если бы показывали - база данных вам бы не позволила дселать что-то нехорошее.

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

Answer 2

[v- smerti]

не надо yii для реста!! юзай композер + нужные либы.
а авторизация проста. Серверу шлём логин/пасс и получаем jwt

ну а я бы посоветовал oauth server https://github.com/willdurand/BazingaOAuthServerBu...

Comments

[Сергей Протько]

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

[Антон Штинов]

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

[copal]

Антон Штинов: а что Вы имеете ввиду под

как быть с роутингом в зависимости от роли,

[Сергей Протько]

Антон Штинов: uiRouter, ресолверы (resolvers). Это решает где-то 70% проблем. Остальные 30% проблем - как решить что показывать а что нет. Ну и все ограничения дублируются на бэкэнде в любом случае.