#http #web-applications #web
#http #веб-приложения #веб
Вопрос:
Допустим, у меня есть веб-сайт, который позволяет любому пользователю входить в систему через oauth или аналогичный, но разрешает только определенные виды использования для создания или изменения содержимого. Если они каким-то образом отправят запрос на страницу для создания нового сообщения, я проверю и перенаправлю их, если у них нет соответствующих разрешений.
В этой ситуации считается приемлемым перенаправление на страницу с ошибкой 403? Не было фактического HTTP-ответа с кодом состояния 403, не было запроса на уровне базы данных или сервера, который был сброшен — только моя бизнес-логика. Я неправильно использую идею кодов состояния HTTP, если я обслуживаю страницу с ошибкой 403 с конкретным пояснительным сообщением?
Комментарии:
1. Пока в ваших документах API указано, что именно этого должен ожидать клиент, это действительно зависит от вас.
2. Я просто обеспокоен тем, что я как-то жестоко обращаюсь с REST здесь.
3. w3.org/Protocols/rfc2616/rfc2616-sec10.html просто указывает, что код «403 Forbidden» — это сервер, подтверждающий, что запрос был правильно сформирован, но сервер отказывается его обрабатывать. Я думаю, что это соответствует (как я предполагаю) вашей политике ACL. Я бы просто убедился, что вы отправляете открытый текстовый ответ о том, почему запрос не обрабатывается.
4. извините, я думаю, что неправильно истолковал ваш вопрос. Мое предложение применимо только в том случае, если это RESTful API. Если это веб-страница, то вы должны вернуть код «200» и объяснить на странице, что у пользователя нет привилегий для выполнения указанного действия (или просто проигнорировать запрос и перенаправить их на какую-нибудь нормальную страницу по умолчанию).
Ответ №1:
Вы можете это сделать, но я думаю, что если вы хотите предоставить API, вы бы использовали фактический ответ 403, потому что они несут значение, которое будет хорошо обработано клиентом.
Если вы хотите отобразить страницу клиенту и будете использовать перенаправление, вы потеряете это значение «403».
Не лучше ли просто перенаправить их на страницу объяснения, не включая код «403». Или, что еще лучше, перенаправьте их в более полезное место, например, на страницу регистрации, если это то, что им нужно сделать, чтобы опубликовать сообщение, или обратно на исходную страницу с плавающим сообщением.
Мы хотим помочь пользователю приблизиться к своим целям, а не путать их с кодами технических ошибок.
Ответ №2:
Часто по этой теме много дискуссий, и все сводится к следующим вариантам:
- 5xx? Конечно, нет. Это не ошибка сервера.
- 400? На самом деле, это не был неверно сформированный запрос.
- 401? Вероятно, нет, 401 обычно предназначен для авторизации в целом, а не для разрешений на уровне приложения. Если ваш пользователь уже вошел в систему, но у него неправильная роль, и вы хотите сообщить об этом пользователю, тогда используйте что-нибудь еще.
- 404? Возможно, поскольку сервер не может найти ресурс для этого конкретного пользователя, но если вы хотите сообщить пользователю: «Ну, такой ресурс доступен, но вы не можете его получить, потому что у вас нет разрешений», тогда выберите что-нибудь еще.
- 403? На самом деле, это имеет большой смысл. Вот определение из RFC
403 запрещено Сервер понял запрос, но отказывается его выполнять. Авторизация не поможет, и запрос НЕ СЛЕДУЕТ повторять. Если метод запроса не был HEAD и сервер желает обнародовать, почему запрос не был выполнен, он ДОЛЖЕН описать причину отказа в сущности. Если сервер не желает предоставлять эту информацию клиенту, вместо этого можно использовать код состояния 404 (не найден).
В вашем вопросе вы упоминаете о своем намерении перенаправить пользователя. Если вы создаете веб-службу RESTFUL, просто верните 403. Если вы создаете целое веб-приложение, вы можете управлять 403 и перенаправлять….
Комментарии:
1. То, что делает 403 сомнительным, — это часть «Авторизация не поможет», что делает ее безусловной, в отличие от зависимости от доступа пользователя. Авторизация помогла бы, если бы у пользователя был правильный доступ, и запрос следует повторить, если пользователь может предоставить соответствующие учетные данные.