JavaScript фреймфорк + права пользователей + интерфейс
Есть backbone.js или angular.js, или какая-либо похожая неведомая хрень. На бэкенде есть express.js. На выходе получаем одностраничное приложение, которое работает без перезагрузки.
Пользователь авторизуется и получает роль, допустим "пользователь обыкновенный". Он имеет на сайте определенные права, от которых зависит интерфейс: дополнительные кнопки, функции и т.д.
В какой-то момент, пока пользователь на сайте, админ дает ему другую роль, допустим "пользователь привилегированный". В этот момент у пользователя должны появиться новые функции, кнопки и другие элементы интерфейса.
Судя по всему нам нужно уведомить пользователя, можно использовать socket.io, а на клиенте сделать обработчик события, который в свою очередь будет добавлять нужные элементы интерфейса.
Так вот, верно ли я мыслю?
И второй вопрос: все эти элементы интерфейса хранить постоянно на странице и показывать/прятать при смене ролей пользователя или же изменять dom каждый раз?
Прослушивать событие change у модельки. Админ дает новые права (читай - сетит новые данные в модель), триггер change срабатывает и твое представление рендерит новый шаблон, где уже есть все эти кнопочки привелегированного юзера. (это на бэкбоне, на ангуляре думаю как-то похоже)
Мыслете вроде верно. Тоже сейчас делаю такое приложение на AngularJS + Spring. На клиенте хранится объект авторизации с некоторыми данными пользователя (имя, роли) - в специальной службе. Так же, как и на сервере. Этот объект запрашивается один раз и обновляется по мере надобности (после редактирования профиля, например).
Но вот заморачиваться с обновлением прав, если администратор их поменял, я пока не стал. Роли пользователя остаются в силе на всё время действия авторизации. Нужно ведь обновлять авторизацию как на клиенте, так и на сервере, а потому нужно на сервере держать список всех авторизованных пользователей... ну его.
Но если сильно надо - то есть альтернатива socket.io и веб-сокетам. Можно обновление данных авторизации передавать вместе с обычными ответами сервера. Например, в HTTP-заголовках. При этом в AngularJS можно перехватывать все ответы, и, если такой заголовок найден, менять данные авторизации на клиенте. На стороне сервера передачу таких заголовков можно выполнять с помощью специального фильтра, чтобы не заморачиваться с каждым отдельным запросом...
Перечитал все статьи по angular, делал проверку в rest, если пользователь запрашивал данные, к которым не имел доступа и стал 401 ошибку. Но angular, вначале переходил на страницу, а потом уже сообщал, что нельзя. Сталкивались с таким?
А что значит "переходил на страницу"? На какую? Как сервер вообще может сообщить статус, не перейдя на какую-то страницу? 401 значит "требуется аутентификация". Как правило, этот статус выставляется страницей входа. Мой сервис аутентификации перехватывает 401 и показывает диалог входа. Реализован по аналогии с этим. Естественно, страница входа у меня своя - она содержит короткий JSON-ответ (можно и пустой ответ слать) и выставляет статус 401. Всё работает как часы...
Если поразмыслить, то мало скрывать-показывать элементы - для этого можно использовать, как вы правильно сказали, rootScope + директивы (ng-if, ng-hide).
Нужно еще ведь и отдачу данных ограничить - обычный пользователь не должен получать от сервера данные, которые не может видеть.
Т.е. недостаточно, на мой взгляд, просто скрыть колонку в таблице, если данные для этой колонки все равно прилетают с сервера.
Чтобы асинхронно получить данные то нужно либо сокет использовать либо long poling(в кратце это такой способ общения с сервером когда клиент даёт гет-пост запрос на сервер но сервер отвечает не сразу а отдаёт данные как только они появляются). Что то из этого тебе должно помочь.
И второе, а что тебе мешает изменить dom каждый раз ? Если ничего то каждый раз и меняй.
Средний
