Отрисованные шаблоны на стороне сервера для AngularJs

0

Я создаю сложную веб-страницу, в которой есть много пользователей/групп/разрешений, где пользователь может видеть все /some/none объекта определенного типа в соответствии с ACL (используя Symfony2 и Symfony2 ACL).

Теперь я имею в виду, что я не хочу показывать каждый элемент пользовательского интерфейса в интерфейсе и просто бросать ошибку 403, если пользователь делает то, на что у него нет разрешения. Элементы Hidding, которые пользователь не имеет права видеть, были бы лучше для UX.

Это похоже на то, что если я показываю страницу информации о продукте для пользователя, я не хочу показывать кнопки EDIT/DELETE, если у пользователя нет разрешения на выполнение этого продукта или всех продуктов (разрешение области класса).

С помощью шаблонов Twig и на стороне сервера это было бы легко, так как добавление кучки проверок разрешений в шаблоне

{% if is_granted('EDIT', product) %}
    <button>Edit product</buttom>
{% endif %}

Но как справиться с этим у клиентов с AngularJs?

Я подумал следующее:

  1. Создайте метод контроллера, который обслуживает Twig-шаблоны для серверной части для AngularJs. Это принимает параметр id идентифицирующий объект, для которого пользователь должен иметь разрешения, чтобы видеть кнопки EDIT/DELETE, представленные в шаблоне (Twig и is_granted() обрабатывает этот серверный сервер)

  2. Пользователь просит просмотреть конкретный продукт /product/1. Маршрутизатор templateUrl будет /templates/product/view.html?object_id=1, где object_id идентифицирует объект, который должен использоваться при рендеринге шаблонов serveride для предоставления или отказа от рендеринга элементов ui.

  3. Затем продукт JSON извлекается и помещается в шаблон, который уже был обработан сервером, и имеет некоторый угол {{ }} ожидающий размещения данных о продуктах.

Существуют ли какие-либо подобные случаи, разрешенные с использованием других технологий serveride, с которыми вы знакомы, и их можно взять в качестве примера, чтобы привести меня к своему успеху?

Теги:
twig

1 ответ

0

На клиентской стороне нашего проекта достаточно углового кода.

  • Задняя часть никогда не будет отправлять какие-либо данные для конечного пользователя, у которых нет разрешения на просмотр/доступ. (403)
  • Передняя конечная страница входа в систему для пользователя с пользователем ведьмы может аутентифицироваться. Передняя часть отправляет предоставленные учетные данные обратно, что отвечает за фактические проверки.
  • Задний конец предоставит Front end роль пользователя/права доступа/привилегии. Если это более сложные выделенные конечные точки API, будут предоставлены. (Fe: Может ли пользователь получить доступ к этому? Be: Нет. Fe: that? Be: Да, но не удалять и т.д.)
  • Передняя часть будет использоваться, если по данным, возвращаемым с Back end, для условного отображения частей пользовательского интерфейса.

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

Для Angular мы создали службу CurrentUser которая is('role_name'), которая вернет true, если пользователь назначил роль, иначе false. ng-if или plain old if(), а затем, когда используется для условного рендеринга html-тегов/данных.

  • 0
    Мне нужно проверить разрешение пользователей на конкретный объект для конкретного действия (VIEW / CREATE / EDIT / DELETE). Я думаю, что вызов API для проверки этого на каждом объекте не будет эффективным.
  • 0
    Можете ли вы расширить API, чтобы он отправлял ACL вместе с данными каждый раз, когда клиент запрашивает его? Затем вам нужен какой-то сервис, который декодирует эти данные acl, но в пользовательском интерфейсе он все еще один, если на действие.
Показать ещё 1 комментарий

Ещё вопросы

Сообщество Overcoder
Наверх
Меню