Если представление RESTful зависит от прав пользователя?

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

Если вы используете сессии это будет Stateful часть процесса: Например, если вы хотите, чтобы прочитать страницу профиля кого-то, вы будете иметь 2 представления: users/123 и users/123?editable=true. Это зависит от разрешений сеанса, можно ли выбрать редактируемый. Где должна появиться редактируемая ссылка? Если он отображается в представлении /users/123 только в том случае, если у вас есть разрешения, он нарушает ограничение безгражданства службы, поскольку представление ресурса будет зависеть от разрешений текущего сеанса. : S Итак, если вы хотите иметь различное представление для каждого пользователя, тогда вам нужно отправить что-то об этом с каждым запросом.

У кого-нибудь есть хорошее решение для этого? Можно ли использовать сеансы и отделить часть состояния от службы?

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

источник

2013-12-01 inf3rno

Если вы отправляете учетные данные (явные или защитные маркеры) по каждому запросу и проверяете авторизацию по каждому запросу, вы по-прежнему без гражданства без сеанса на сервере REST, чтобы помнить, кто ранее был зарегистрирован, поэтому я считаю, что он все еще RESTful, возможно, можно рассматривать заголовки запросов (например, аутентификацию/авторизацию) как неявную часть вашего запроса REST. – zenbeni

Я так не думаю, у вас есть очень простые правила по авторизации. Если пользователь не вошел в систему, ответ должен быть 401. Если она вошла в систему, но не авторизована, тогда ответ должен быть 403. Если она авторизована, то по запросам GET ответ должен представлять собой представление ресурса , Такого правила нет, что если пользователь авторизован, то она должна получить представление ресурса, а если нет, то она должна получить другое представление ресурса ...Если вы хотите, чтобы ваше представление оставалось без гражданства и кэшируемым, вы должны соблюдать эти правила ... – inf3rno

У вас, кажется, неправильное представление о безгражданстве и представлениях. REST означает «REpresentational State Transfer». Короче говоря, сервер передает состояние своих ресурсов через представления тех ресурсов, которые он посылает клиенту. Само сообщение является апатридом ", так что каждый запрос от клиента к серверу должен содержать всю информацию, необходимую для понимания запроса, и не может использовать любой сохраненный контекст на сервере" (Fielding, раздел 5.1.3). –

Должно ли представление RESTful быть в зависимости от прав пользователя?

Да.

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

Это состояние клиента, но вы можете отправлять его с каждым сообщением, чтобы оно не нарушало ограничение без гражданства.

Можно ли использовать сеансы и отделить часть состояния от службы ?

Сессии на стороне сервера не допускаются, поскольку они нарушат ограничение без гражданства.

источник

2013-12-02 16:00:01 inf3rno

Извините, но я больше не думаю, что я поймите либо ваш вопрос, либо ваш ответ. –

Есть 3 состояния по REST. Существует состояние клиента REST, которое может содержать текущую страницу, загруженную в браузере, личность пользователя, параметры разбивки на страницы и т. Д. Существует состояние ресурсов, и есть состояние приложения, которое является эти два состояния вместе. Связь не зависит от клиента и службы, когда клиент отправляет все с запросом, который необходим для генерации ответа. Если он отправляет идентификатор сеанса, и служба получает идентификатор пользователя из хранилища сеансов, то связь не будет апатридом. – inf3rno

Сервер может решить не выполнять сеансы вообще, поскольку HTTP Basic требует, чтобы клиент предоставил учетные данные, необходимые для аутентификации для каждого запроса. Это в основном то, что вы описываете, когда вы говорите, отправляете идентификатор пользователя с каждым запросом (за исключением того, что вы также отправляете пароль). –

Если представление RESTful зависит от прав пользователя?

ответ

Смежные вопросы