Как обработать бэкэнд-запрос django для вошедшего в систему пользователя способом RESTfull? - PullRequest
Новая
       14

Как обработать бэкэнд-запрос django для вошедшего в систему пользователя способом RESTfull?

0 голосов
/ 20 мая 2019

Я занимаюсь разработкой веб-платформы, которая обеспечивает обработку лицензий (например, создание, выставление счетов, загрузка) для определенного программного обеспечения. Бэкэнд - django 2.1.7 и фронтенд угловой.

У меня есть следующий вариант использования, и я хочу убедиться, что он уважает архитектуру REST и что он пригоден для будущего (избегайте ловушек).

Итак, у меня есть 2 apis:

  • ф / userprofiles
  • ф / лицензия

Эти 2 apis защищены и доступны только после входа в систему.

В моей текущей реализации GET запрашивает для этих 2 API-интерфейсов возврат только данных, относящихся к зарегистрированному пользователю, путем извлечения идентификатора и имени пользователя из информации request.user (то есть для аутентифицированного пользователя). 

User with user1 name logged in (NOT admin).
GET ip/userprofiles will return user1 profile.
GET ip/licences will return user1 licences.

Другой вариант использования: администратор должен иметь доступ ко всем лицензиям и всем пользователям, и для этого я проверяю, является ли request.user администратором. 

User with user10 name logged in (user10 IS admin):
GET ip/userprofiles will return ALL users profiles.
GET ip/licences will return ALL licences (for all user).

Для пользователей-администраторов apis также позволяет выполнять фильтрацию по пользователям, используя параметр строки запроса.

Является ли этот подход приемлемым с точки зрения REST, а также с точки зрения безопасности? Любые подводные камни, которые я должен остерегаться?

Должен ли я использовать для пользователей без прав администратора тот же подход, что и для пользователей с правами администратора, чтобы указать текущий идентификатор пользователя в качестве параметра строки запроса во внешнем интерфейсе, а не извлекать пользователя в бэкэнде из request.user (аутентифицированный пользователь) Информация)? Это решение не кажется мне безопасным, но может стать ограничением на будущее (хотя в настоящее время я не вижу ни одного варианта использования, в котором пользователь должен иметь доступ к лицензиям и профилям других пользователей)

1 Ответ

1 голос
/ 21 мая 2019

Лично я не согласен с тем, что вы качаете. Каждая конечная точка API должна иметь одну ответственность за действие запроса. Запрос GET на ip/userprofiles должен всегда возвращать отдельный объект или список объектов. Это упрощает логику клиента, чтобы он мог последовательно переводить результат.

Вот что я бы предложил: 

# Detail / Single Object Endpoints:
ip/userprofile
ip/license

Эти два всегда возвращают текущий профиль пользователя и лицензию соответственно независимо от статуса администратора. 

# List Endpoints
ip/userprofiles
ip/licenses

Эти два всегда возвращают список пользователей и лицензий соответственно, но будут иметь некоторую проверку (в DRF-классе разрешений), которая будет возвращать данные, только если request.user является администратором. Если пользователь не является администратором, он вернет ошибку 403.

...