Корректно ли использовать статус 401 для страниц, требующих авторизацию? На данный момент, если не авторизованный пользователь заходит на такую страницу, то без редиректов отображаю форму авторзиации. При этом страница имеет статус 200. "Чувствую", что это не совсем правильно. Разработчики symfony, видимо, тоже споткнулись о те же грабли
какую авторизацию? Если HTTP, тогда там вообще нет "страницы" - только готовая форма, создаваемая браузером по запросу header('HTTP/1.0 401 Unauthorized'); Если речь об авторизации на куки (через HTML форму вводится пароль и логин), тогда обычный статус 200 ОК.
stopkran Естественно, авторизация с использованием формы. вот тут и возник вопрос, следует ли использовать "обычный" статус Допустим есть статья Код (Text): http://example.com/article/white-rabbit.html // Форма авторизация, статус 200 http://example.com/article/white-rabbit.html // Конкретная статья, статус 200 В первом случае я не вижу что какие-либо данные были отправлены клиенту
это спор о терминах. Что такое "данные"? Для протокола HTTP это просто последовательность символов. (В нашем случае это символы "<form action=...")
Мне кажется что статус 200 это статус ОК - страница существует и если выползла форма авторизации она и вправду существует. А имеет ли человек право её читать это уже не относится к статусам. Есть статус 401 401 Unauthorized The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" [43]. Но он скорее к зашифрованным данным - нет?
По адресу http://example.org/auto/bmw/ расположена информация об автомибеле БМВ, и это никак не форма авторизации. Поэтому и считаю статус 200 непременимым Спецификацию, естественно читал, 401 требует включить в заголовок ответа WWW-Authenticate, а это прямое указание браузеру запросить логин/пароль у пользователя
Я больше всего клонил к тому что одна фаза работы с сайтом - это работа с сервером - конец который вы получаете через статус 200, 401. А другая часть работы - работа обработчика файлов. В общем то от вашей авторизации не меняется механизм работы сервера - и заголовки в общем то те же. Странно при этом выступать в роли сервера и указывать постфактум что например страница зашифрована...Когда она на самом деле нет. Наверное есть только одно исключение это 404 - но там так и написано - страница не найдена, или если додумать - сервер не смог сформулировать вам динамическую страницу а значит так же её не нашёл. Может я конечно не прав....
Feiron Точно так же как статус 404 означает "Страница не найдена" 401 может означать "Страница есть, но я её вам не покажу, потому что у вас документов нет"
Нет не совсем даже в спецификации написано что сервер сразу ожидает заголовок с авторизацией - и если не получает рубит все. А тут то человек получает страницу форму, баннеры с рекламой. И вот если например ЧПУ и 401 - то вы же не получите ответ например с таким ид нету, а типа если есть 401 авторизуйтесь. Вы получите же сразу 401 авторизуйтесь на наглядном белом окошке даже если в конце с таким ид док найден не будет, а в случае доступа по группам на уровне пыха вы получаете опятаки баннеры и манерную форму. Я опять клоню к той же разнице....Нет? )
401 использовать нельзя, у него другие задачи. Используйте 403. Или 30x редирект на форму авторизации. Или просто не парьтесь, ибо никому кроме поисковиков до этого вообще нет дела, а поисковикам по большому счету тоже.
MiksIr У 401 и 403 действительно разные задачи. Использовать 401 действительно нельзя (но только лишь по тому что для него существует одна форма авторизации). Но логически ему самое место на такой странице, в отличии от 403
Статусы не для людей - статусы для машин. А у машин нет расплывчатой человеческой "логики", там жесткие правила. Допустим, будет статус 49000 аналогичный 401, но без WWW-Auth... кому какая польза от этого будет? Машинам - никакой, поскольку они ничего сделать с этим не могут - эта страница для людей. Просто показать машинам, что это не настоящая информация - так уже есть 403. 401 же был сделан с одной четкой целью - запросить у _машины_ авторизацию, а не у людей (а уж что там дальше машина будет делать - не важно). Так что все логично.
не согласен Мне достаточно иметь 401-ый статус без WWW-Auth, например WWW-AuthManual Вот смотрите, приложение ajax-ом запрашивает содержимое страницы, у нас может быть много вариантов, остановимся на четырёх: 200 - получен контент, выполняем действия 304 - контенет не изменён, ничего не делаем 401 - для просмотра контента вывести форму авторизации 403 - у пользователя недостаточно полномичий для получения контента. Как один из вариантов можно на все ajax-запросы отдавать json-ответ в виде массива из двух элементов: content и status Но ведь у нас уже есть инструмент сообщающий о результате - это статус полученный в заголовке, нам не нужно усложнять протокол передачи данных, всё что нужно - правильно обработать ответ от сервера средствами JavaScript и принять решение. То же самое для поисковиков: незачем индексировать страницу требующую авторизацию. Поисковик, в лучшем случае, просто проигнорирует её. Для пользователей статусы не нужны, им контент подавай, любой. Они сами смогут прочитать то, что написано на странице и выполнить определённые действия. Но каждый пользователь это не только человек, но ещё и браузер, который и пользуется статусом страниц только лишь для того, чтобы сделать жизнь конечного пользователя лучше.
Ajax приложению выдавайте 401, никому хуже от этого не станет. Ajax приложение в данном случае - это та самая машина. Поисковику же достаточно 403.