Авторизация в AngularJS приложении

Бэкэнд может выдать список всех разрешений? Если нет, замени его на вменяемый.

Фронтэнд может сделать мап вида страница→разрешение (и элемент страницы→разрешение если, например, на редактирование оно отдельно и нужно скрывать/отключать его в гуе) и сопоставить с выданным бэкэндом списком (который можно получать один раз)? В чём проблема?

Один раз могу запросить еще где-то этапе входа пользователя в систему но вот дальше как? Я пробовал получить доступ к тем cookie что приложение оправляет при каждом запросе к серверу но это мне не удалось. Можно хранить в localStorage но там будут храниться все состояния пользователей и не ясно как выбрать нужные.

Есть мысль написать это на back-end в виде функции check которая будет проверять можно ли юзеру смотреть страницу или нет,

На бэкэнде вообще никаких проверок нет что-ли? О_о.

Куки кстати далеко не лучший выбор. Лучше использовать токены. https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-to...

По случайному совпадению сейчас тоже вожусь с аутентификацией и авторизацией. Использую таки куки :3

В run есть что-то вроде этого:

$rootScope.$on("$routeChangeStart", function (event, next) {
    next = next.hasOwnProperty('$$route') ? next['$$route']['name'] : false;
    rpc.call('user.is.authorized').then(
        function (response) {
            var isAuthorized = response['is_authorized'];
            var roles = response['roles'];
            if (angular.isString(next)) {
                var redirect = false;
                if (isAuthorized) {
                    redirect = ['login', 'register'].indexOf(next) !== -1;
                } else {
                    redirect = next == 'logout';
                }
                if (redirect) {
                    $route.redirect('error');
                }
            }
            var defend;
            for (var navItem in navList) {
                if (navList[navItem].hasOwnProperty('defend')) {
                    defend = navList[navItem].defend;
                    navigation.display(navItem, isAuthorized ? defend : !defend)
                }
            }
            navigation.display('users', roles.indexOf('ROLE_ADMIN') !== -1);
        }
    );
});

А это даст уникальность данных для каждого пользователя? Чтобы не было аврала данных с которых не понятно которые твои.

А rpc это у тебя запрос к back-end?

Не вижу проблем. На бэкэнде всё равно проверяются права доступа, ведь так же? А на фронтенде ты просто хранишь в памяти инфу о текущем юзере. Куки будут слаться с каждым запросом к бэкэнду и без тебя. Тебе нужно только знать текущее состояние юзера, чтобы определять, что показывать на фронтенде.

Ну да. JSON-RPC.

Они будут проверяться, вот я просто озадачен тем что проверять права доступа при каждом изменении route будет очень напряжно в плане каждый раз слать запрос к серверу на проверку доступа. А вот если раз отправить и потом в локальное хранилище положить какие-то маячки для проверки доступа и не ломиться потом на сервер. Но меня волнует вопрос - к примеру я ложу все это в localStorage для каждого пользователя оно будет свое или там грубо говоря будут собираться данные всех пользователей и не понятно какие именно нужные мне?

/api/whatever/whoamiandwhataremypermission, возвращающий что угодно. Хранить — да чем угодно, хоть сервис (в терминах angular) делай, кэширующий это. Нафиг кукизы/localstorage?

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

С локальным хранилищем тебе скорее всего придётся обрабатывать ситуацию, когда срок действия токена истёк, но он всё еще находится в локальном хранилище. Вобщем оно всё только усложнит, а польза сомнительна. ИМХО, конечно же.

Честно может не до понял, что именно ты имеешь в виду по памятью в данном контексте? Что-то типа Redis, о какой памяти тут идет речь?

Та, что выделяется под переменную.

Как-то так это будет выглядеть наверное:

module.factory(
    'auth',
    function ($q, rpc) {
        var userInfo = null;
        return {
            info: function () {
                var deferred = $q.defer(); 
                if (userInfo == null) {
                    rpc.call('user.info').then(
                        function (result) {
                            userInfo = result;
                            deferred.resolve(result);
                        },
                        function (error) {
                            deferred.reject(error);
                        }
                    );
                } else {
                    deferred.resolve(userInfo);
                }
                return deferred.promise;
            }
        }
    }
);

Ок, буду пытаться реализовывать для себя это все, эта factory даст уникальные данные для каждого пользователя выходит?

А почему нет? Откуда вообще такие опасения? Идёт запрос на бэкэнд с куками или без, которые были установлены у этого юзера. В переменной userInfo сохраняется ответ от бэкэнда. Как туда данные другого юзера могут попасть? Я не представляю. Даже если что-то и пойдёт не так, то бэкэнд не позволит ничего сломать.

Ок, буду разбираться, если где-то что-то не пойму правильно, буду этот топик продолжать.

Выходит эта factory инжектится в каждом controller-е где нужна user info?А вот еще вопрос назрел

rpc.call('user.is.authorized').then(
        function (response) {
            var isAuthorized = response['is_authorized'];
            var roles = response['roles'];

http://code.re/76R

Спасибо, изучу.

И вновь я) вот ссылка на небольшой кусок моего кода, есть одна проблема которую пока не удалось решить http://code.re/77d если что строго код не суди, он пока прототипный в плане что только начинает описывать концепцию общую, сама проблема вот в чем, написал я сервис auth и в обработчике события $routeChangeStart делаю необходимую проверку основываясь уже на установленном cookie при логине, но вот в чем незадача, я прошел процедуру логина, и дальше в шаблонах вывожу имя и логин юзера, но сразу после логина он не выводиться, как только перезагружаю страницу то в шаблонах появляется нужная инфа, как я понимаю при перезагрузке страницы происходит boostrap самого приложения, я на этапе 200 ответа при логиче хотел в rootScope записать эти нужные значения, а там дальше уже за них отвечал бы сервис auth, вопрос в том как правильно это сделать, что-то в роде rootScope.reload чтобы уже сразу после логина нужные данные попадали в шаблоны.

и дальше в шаблонах вывожу имя и логин юзера, но сразу после логина он не выводиться

И не будет, потому что run выполняется только один раз.

Можно сделать директиву и этого должно быть достаточно. Нужно только не забывать обновлять userInfo.

Ещё один вариант — через события. Опять же в $rootScope подписываешься на какой-нибудь auth и обновляешь данные. При логине/выходе генерируешь событие auth и всё. Только что-то мне подсказывает, что так делать не надо. В $rootScope лучше вообще ничего не хранить и завязывать сервисы/контроллеры на него тоже не стоит. ИМХО.

А какого плана директиву ? На что направленную?

Можно ли как-то на фоне сделать run?

Забудь про директиву. Ха-ха. У нас же только обещание можно вернуть и при изменении данных юзера как ни крути придётся юзать эвенты. Могу ошибаться конечно.

Что значит на фоне?

С эвентами возился но не получилось, попробую еще раз только немного другим способом. А в фоне значит - пришел ответ с сервера что пользователь авторизован, ну и я перед редиректом на главную делаю re-boostrap приложения, что могло бы дать нужный результат, но как это сделать и возможно ли это - я не знаю.

ну и я перед редиректом на главную делаю re-boostrap приложения

Зачем так делать? Вот пример с эвентами: http://codepen.io/anon/pen/EaZbMm

Ок. Буду пытаться отталкиваться от этого.

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

При смене роута, где же ещё. Можешь сделать сервис, который будет отвечать за проверки и вызывать метод, который определяет доступ при этом событии. Чтобы run сильно не перегружать.

Ну да как-то так и буду)

где же все таки эту проверку цеплять.

В параметре resolve внутри определения route.