Как обеспечить разрешения уровня ресурса с OData

Question

Я читал документацию по OData, но мне не удалось найти ничего об управлении доступом на уровне ресурсов.

В примере с OData человек russellwhyte выбирает поездку 1003. Но как я могу проверить, что запрашивающий имеет доступ как к People = 'russellwhyte', так и к Trip = 1003? Что если запрашивающий имел доступ к «rusellwhyte», но изменил поездку 1003 на 1004, принадлежащую другому лицу, и, следовательно, запрос должен быть отклонен, поскольку 1004 принадлежит другому лицу и поскольку заявитель не имеет доступа к поездке 1004 .

GET
serviceRoot/People('russellwhyte')/Trips(1003)

Запрос выше может быть отклонен по трем причинам:

1. Запрашивающая сторона не имеет разрешения на доступ к данным russelwhyte.
2. Запрашивающая сторона не не имеет разрешения на доступ к поездке 1003.
3. Запрашивающая сторона изменяет идентификатор поездки на недействительный, 1004. (1004 принадлежат другому человеку)

Если это был простой маршрут определение ([Route("people/{personId}/trips/{tripId}")]) Я мог бы получить оба идентификатора из запроса, а затем выполнить необходимые проверки разрешений, но я не нашел их эквивалента для OData.

Answer 1

Когда оценивается trips, он уже должен иметь фильтр personId, например, если tripId не был указан, то выполняемый запрос должен быть чем-то похожим на это выражение Linq to Entities

from p in db.People
where p.Id == personId
select p.Trips

Поэтому, когда присутствует tripId, единственная разница должна заключаться в том, что в ответе применяется дополнительный фильтр поверх предыдущего запроса.

Таким образом, когда неправильный tripId или personId предоставляется, результатом будет либо пустой объект, либо Http 404 , Not Found . (в зависимости от вашей реализации)

Вы не упомянули, какое промежуточное ПО, версию OData или ORM вы используете, так что все спекуляции на OData v4 с использованием ASP. Net ODataLib, мне пришлось реализовать свой собственные логики c на каждом контроллере, который я хотел поддерживать этот тип вложенной навигации, но соглашение было тем же, каждый уровень маршрута навигации добавлял новый критерий к запросу select поверх запроса, предоставленного контроллером родительского маршрута.