REST, кэширование и авторизация с несколькими ролями пользователей - PullRequest
Новая
       20

REST, кэширование и авторизация с несколькими ролями пользователей

8 голосов
/ 20 апреля 2010

У нас мультитенантная система с несколькими различными уровнями доступа - иногда даже для одного и того же пользователя, когда они переключаются между несколькими ролями. Мы начинаем обсуждение перехода к RESTful реализации вещей. Я только начинаю намочить ноги от всего этого ОТДЫХА.

Итак, как мне ограничить доступ к нужным записям, когда они обращаются к ресурсу, особенно с учетом кэширования? Если пользователь A получит доступ example.com/employees, он получит ответ, отличный от пользователя B; пользователь A может даже получить другой ответ, когда он переключается на другую роль. Чтобы облегчить кэширование, должен ли идентификатор роли каким-то образом включаться в uri? Может быть, что-то вроде example.com/employees/123 (что нарушает правила REST), или как какой-то подчиненный ресурс, такой как example.com/employees/role/123 (что кажется глупым, поскольку role/### будет добавляться к URI везде) Я могу помочь, но думаю, что я что-то здесь упускаю.

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

1 Ответ

7 голосов
/ 20 апреля 2010

Наличие учетных данных пользователя в качестве внешнего идентификатора ресурса (т. Е. Представление разных представлений одного и того же URL-адреса для разных ролей) приведет к неприятным последствиям. Пользователи и приложения обмениваются URL-адресами между ними, когда это происходит, все становится плохо, и URL просто возвращает разный контент для разных учетных данных.

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

  • администраторы подключаются к example.com/admin/employees
  • пользователи подключаются к example.com/users/employees
  • роль foo, вероятно, подключается к example.com/foo/employees

Таким образом, вы отделяете часть «эта роль видит мир как таковой и такой» от части «эта точка зрения на мир доступна для роли». Администратор может подключиться к example.com/users/employees и проверить, как обычный пользователь видит мир, без того, чтобы администратору сначала пришлось выдавать себя за более низкий привилегированный псевдоним.

Вы также можете использовать часть DNS для той же цели: admin.example.com/employees против users.example.com/employees. Это особенно актуально для связанного сценария, когда «роль» - это не роль безопасности, а мультитенантное пространство имен (т. Е. Каждая учетная запись, предоставленная службой, получает свое собственное «представление» службы).

...