Конечная точка сервера REST для проверки, имеет ли прошедший проверку пользователь доступ или разрешение на выполнение действия

0

У меня есть приложение с угловыми одностраничными страницами, в котором пользователи могут создавать список вакансий. Я хочу контролировать, может ли пользователь редактировать список заданий. Есть две роли, которые могут редактировать список заданий. Аутентифицированный пользователь, который может редактировать свой список вакансий или администратор, который может редактировать все списки вакансий.

Сервер будет проверять, имеет ли пользователь доступ к этим действиям. Это не проблема. Тем не менее, перед изменением состояния в клиентском приложении, я хочу сделать запрос на сервер, чтобы проверить, имеет ли текущий зарегистрированный пользователь разрешение. Таким образом, запрос будет проверять, может ли пользователь редактировать список заданий С#id 9de88893, например.

Как выглядит этот маршрут. Он возвращает только истину или ложь? Я даже не представляю, как это выглядит и как это будет работать. Есть идеи?

  • 0
    Как выглядит интерфейс? У вас есть страница со списком вакансий, а затем кнопка редактирования? Вы можете скрыть кнопку редактирования, если у них нет разрешения. Вы также можете создать и зарегистрировать некоторое промежуточное программное обеспечение и прикрепить его к некоторым маршрутам, которые вы хотите защитить за разрешениями.
  • 0
    Репозиторий находится на GitHub . Мне нужно разрешение с именем editOwnJob, которое позволяет пользователю редактировать список вакансий, которые они создали. Но проверка происходит в контроллере в приложении Angula, который, кажется, не лучшее место для логики. Я думаю о создании конечной точки example.com/api/… Я просто хочу знать, что обычно делают разработчики?
Теги:
express
rest
access

2 ответа

0

Я сделал угловой проект запуска 1.5.x вы можете посмотреть на этой (строке 140).

Чтобы идентифицировать пользователя, вам нужно будет отправить токен с каждым запросом от клиента (Угловое).

Сервер проверяет токен и анализирует его (теперь зная, что пользователь запрашивает для изменения ресурса), затем решает курс действия в соответствии с этим пользователем (поскольку токен зашифрован с помощью секретности сервера).

Проверка доступа должна быть на стороне сервера, иначе она НЕ защищена!

  • 0
    Система уже имеет промежуточное программное обеспечение на сервере для проверки ролей пользователя и необходимости предоставления доступа. Я просто хочу защитить форму клиента от случайного использования. Например, как StackOverflow мешает мне редактировать ваш профиль на клиенте? Не только сервер.
  • 0
    Правда. Я неверно истолковал ваш вопрос. Что касается вопроса: если у вас ничего нет в модели (объект пользователя), вы можете использовать для проверки, тогда да, вам нужно будет запросить сервер, чтобы отключить некоторый элемент пользовательского интерфейса.
Показать ещё 2 комментария
0

Во всяком случае, и, как сказал Мули выше, аутентификация должна производиться на стороне сервера. По соображениям безопасности.

Вот учебник, который поможет вам в создании системы аутентификации маркера, которая работает с угловым.

https://thinkster.io/angularjs-jwt-auth


Хорошо, поэтому, если я правильно понял, вы обеспокоены тем, что кто-то может заставить ваш фронт... Ну, говно случается человек. Именно поэтому вы ДОЛЖНЫ всегда проверять на стороне сервера каждый запрос. В качестве примера у меня есть веб-приложение, основанное на Angular и Laravel (как спокойное обслуживание). Все, я имею в виду ALL, ранее запрашиваются запросы, если пользователь действителен, прежде чем принимать, изменять или создавать какую-либо строку в БД.

В вашем случае я буду использовать роли пользователей на угловой стороне и проверять каждый запрос на стороне сервера. Вы можете сделать функцию, которая проверяет, зарегистрирован ли пользователь, и дать ему флаг для проверки прав пользователя. Если у вас нет доступа к этому запросу, отправьте ответ состояния 403 и затем покажите любое предупреждение, которое вы хотите на угловой стороне. Таким образом, с помощью управления пользователями и состояниями пользователей вы можете запретить пользователям совершать посадку на странице x. И на стороне сервера предотвратите любые принудительные попытки.

Front-end легко взломать, это факт. Вот почему мы все время проверяем на стороне сервера.

  • 0
    Аутентификация производится на сервере. Я беспокоюсь об аутентификации на клиенте, чтобы пользователи случайно не оказались на странице редактирования для ресурса, к которому сервер не имеет доступа. Мне любопытно, как сначала проверить сервер, если у пользователя есть доступ, прежде чем представлять форму пользователю.
  • 1
    Иди с ролями. Таким образом, штаты решат, может ли зарегистрированный пользователь получить доступ к х странице ... вот еще один учебник ... arthur.gonigberg.com/2013/06/29/angularjs-role-based-auth
Показать ещё 2 комментария

Ещё вопросы

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