Как представить элемент управления доступом уровня атрибута RESTful?

Я разыгрывал свой мозг и искал надолго, не придумывая удовлетворительный способ справиться с этим. Я хочу написать хороший сервис RESTful для возврата ресурсов, но у вас есть разрешение на чтение (или запись) каждого ресурса в зависимости от вашей роли. Так, например, пользователь может видеть свой частный номер телефона в своем профиле, и поэтому может быть администратором сайта, но другой пользователь этого не сделает. Анонимный посетитель, возможно, не сможет увидеть реальное имя другого пользователя, но могут использовать другие пользователи (и администратор сайта). Существует около 4 или 5 уровней доступа и правил, по которым атрибуты могут быть прочитаны или записаны. Письмо мне доставляет удовольствие, так как клиент может PUT изменения, и сервер не обязан принимать их все (или вообще), но чтение - это моя проблема.

<user>
 <id>jimbob</id>
 <real-name>Jim Roberts</real-name> <!-- only logged-in users should see this -->
 <phone-number>+1 42424151</phone-number> <!-- only the user and admin users should see this -->
</user>

Я хочу иметь правильно кэшируемый ресурс профиля пользователя, который содержит все общедоступные данные, но как я могу моделировать все материалы, которые могут видеть только определенные пользователи? Я мог до 4 ссылок на дополнительную информацию, большая часть которых возвращала бы несанкционированные ошибки для большинства пользователей, причем каждая ссылка содержала дополнительную информацию, связанную с ролью. Но это кажется очень неэффективным, а также связывает клиентов с концепцией ролей, когда раньше все, о чем им нужно было знать, были пользователями. Есть ли лучшие идеи?

<user>
 <id>...</id>
 <link rel="more" href="extra-user-profile-data-for-logged-in-users"/>
 <link rel="more" href="extra-user-profile-data-for-senior-users"/>
 <link rel="more" href="extra-user-profile-data-for-admin-users"/>
 <link rel="more" href="extra-user-profile-data-for-superadmin-users"/>
</user>

Обратите внимание: я не борюсь ни с одним из

Аутентификация
Контроль доступа на уровне ресурсов
Внедрение контроля доступа или авторизации на стороне сервера

Я борюсь с

Как представлять ресурсы, которые на "нормальном" HTML-сайте будут отличаться от разных людей, по-настоящему RESTful.

Это похоже на действительно общую проблему, которую каждый должен иметь, но я ничего не могу найти на ней! Пожалуйста, помогите!

Ответ 1

Если вы думаете об этом, ресурс User, который видит клиент-клиент (со всеми видимыми полями), точно тот же ресурс, который видит анонимный или менее привилегированный клиент. URI идентичен, но представление, которое они видят, отличается.

Это похоже на то, что запрос клиента должен быть закодирован в JSON вместо XML через заголовок Accept: сервер может согласиться соблюдать этот запрос, но это необязательно. В вашем случае сервер должен вернуть представление, соответствующее предоставленным клиентом учетным данным.

Следовательно, администратор может получать контент в медиа-типе application/vnd.yourcompany.user.full+xml в качестве тела, возвращаемого GET на ресурсе User, и он будет содержать все возможные поля.

Однако анонимный пользователь может получить полезную нагрузку, закодированную, например, application/vnd.yourcompany.user.limited+xml, которую ваша документация будет четко описать как представление, которое может содержать или не содержать все элементы из версии full. Клиент должен будет использовать гибкий декодер или схему, которые допускают определенные элементы, которые не присутствуют вообще.

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

<user>
 <id>jimbob</id>
 <real-name>--FORBIDDEN--</real-name> 
</user>

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

Окончательное решение о том, следует ли возвращать ссылки на другие ресурсы, которые не были бы судоходными, на основе учетных данных, предоставленных клиентом. По-моему, эти ссылки должны быть возвращены всегда, даже если эти учетные данные не будут работать. Зачем? Поскольку клиент может теоретически предоставлять другие учетные данные при вызове этих URI. Даже если они этого не делают, результирующая проблема 401 может привести к тому, что клиент в конечном итоге предоставит их. Но если они никогда не получат URI, им будет запрещено делать это.