Как разграничивать права доступа в API?

Question

[nepster-web]

Продумываю API, возник вопрос с разграничением доступа.
Предположим у нас есть модуль контент (стат. страницы, новости, записи, заметки и тп.). На примере новостей может получится следующее:
- Пользователи могут просматривать и создавать новости
- Администраторы могут просматривать и создавать новости

Однако тут есть одно больное НО:
- пользователи могут просматривать и создавать новости не без манипуляции определенными полями (дата создания, дата редактирования, автор, категория, модерация и тп.)
- администратор обладает куда большими правами и может делать все, что с этим связанно.

Если взять методологию REST и предположить следующие URL:
- /contents/records
- /contents/records/17

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

Используя другой подход, можно разграничить все это дело следующим образом:
- /contents/records
- /contents/records/17
- /control/contents/records
- /control/contents/records/17

Как поступить с подобной задачей ?

Answer 1

[xfg]

Сделать бекенд и фронтенд контроллеры. Через бекенд контроллер можно менять все поля, через фронтенд контроллер не все. Пользователей и Администраторов сделать используя RBAC. Пользователи могут вызывать фронтенд контроллеры и не могут бекенд контроллеры.

Comments

[nepster-web]

Вот я как раз пришел к такой мысли, но разве такой подход не противоречет рест ?

[xfg]

Нет. REST не устанавливает никаких требований к контроллерам. Он предъявляет требования к формату запроса/ответа, но не накладывает никаких ограничений на возвращаемые данные из контроллера. Что конкретно по вашему в этом подходе противоречит рест?

[nepster-web]

xfg: формирование url и дублирование.

[xfg]

site.tld/api/v1/backend/users/1
site.tld/api/v1/frontend/users/1

Где дублирование? Что здесь нарушает рест?

[nepster-web]

xfg: дублирование кода, для реализации стороны бэка и фронта.

[xfg]

nepster-web: не лить бизнес-логику в контроллер и дублирования не будет. Он должен валидировать пользовательский ввод и возвращать результат работы модели. Больше ничего. Валидация и возвращаемый результат у вас будут отличаться у бека и фронта. Никакого дублирования.

Answer 2

[SimBioT19]

Будет полезно:
https://habrahabr.ru/company/dataart/blog/262817/

Comments

[nepster-web]

Это не совсем то, в статье речь идет о аутентификации, у меня это реализовано с помощью JWT. У меня скорее вопрос в простом варианте как разграничивать доступ к определенным полям таблицы ?

Answer 3

[Alexander Pushkarev]

Используйте ключи доступа. Создайте отдельную таблицу KEY | ROLE и потом уже при запросе проверяйте ключ на доступ. Передавать GET параметром или в заголовке запроса

Пример -

/contents/records?key=3c6e0b8a9c15224a8228b9a98ca1531d

Comments

[nepster-web]

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

[SimBioT19]

nepster-web: похоже на задачу "как проверить есть ли доступ к полю при этом ничего не проверяя"

[Alexander Pushkarev]

nepster-web: сколько? Ровно один запрос к базе