Должен ли я вернуть код состояния http 401 в html-форме входа в систему?

Должен ли я вернуть код состояния http 401 в html-форме входа в систему? Страница представляет собой специальную форму входа в систему и не имеет никакого другого значимого контента, кроме структуры сайта. Однако URL может быть для страницы, которая имеет содержательное содержимое, но требует входа в систему. Обратите внимание, что эта настройка возвращает только код состояния 401 и не запрашивает у пользователя обычную аутентификацию.

Глядя на стандарты, кажется, что 401 - неподходящий код статуса для html-форм входа в систему. Однако я никогда не испытывал и не слышал о каких-либо вредных последствиях этого.

При отправке 401 «ответ ДОЛЖЕН включать поле заголовка WWW-Authenticate (раздел 14.47), содержащее запрос, применимый к запрашиваемому ресурсу».

требование, упомянутое здесь:

http://tools.ietf.org/html/rfc2616#section-10.4.2

подробно здесь:

http://tools.ietf.org/html/rfc2617#section-3.2.1

Я знаю, что есть способы обойти поисковики, чтобы убедить их проиндексировать или нет страницы, основываясь на наличии формы входа, но я бы предпочел использовать коды состояния http, в частности 401, так как это определение выглядит как идеально подходит, если не для требования заголовка WWW-Authenticate.

Есть ли причина, по которой я не должен использовать 401 в этом случае? С семантической точки зрения, есть ли разница между отсутствием Авторизации на уровне http и Авторизацией на уровне приложений? Очевидно, что вы можете использовать и то, и другое, но разве аутентификация не выполняется на уровне http только для простоты не реализации ее на уровне приложения?

Как вы заметили, RFC 2616 требует, чтобы ответ 401 сопровождался заголовком RFC 2617 WWW-Authenticate. Я полагаю, что вы могли бы технически выполнить это требование, отправив поддельный заголовок, например:

WWW-Authenticate: Bogus realm="blahblah", comment="use form to log in"

но я понятия не имею, что будут делать браузеры, если будут представлены ответы 401, не содержащие проблем, которые они понимают. Я предположил бы, что большинство, если не все из них, представят тело запроса пользователю (как RFC 2616 говорит, что они должны делать, если аутентификация не удалась), но ни один RFC, кажется, не говорит об этом явно, поэтому они могли бы на законных основаниях просто показать общее сообщение об ошибке. вместо.

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

Хотя в описании кода состояния 403 говорится, что «утверждение не поможет», это следует понимать в контексте IMO как ссылку на аутентификацию RFC 2617 или аналогичные механизмы авторизации на уровне протокола; Что касается браузера, он не имеет представления, считается ли отправка формы и получение куки-файла в ответ «авторизацией» или чем-то еще.

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

В любом случае, если вы используете куки-файлы HTTP для хранения токенов аутентификации после входа в систему, вы должны включить заголовок Vary в свои ответы (как до, так и после аутентификации), чтобы предотвратить неправильное кэширование, как в Vary: Cookie.

Во-первых, если странице нужен логин, вам, вероятно, следует заблокировать ее с помощью robots.txt

Во-вторых, если роботы достигают страницы, возникает ошибка 401.

возможно, коды состояния могут быть полезны для не-человека [и для некоторых браузеров? ]

независимо от метода входа в систему, правильный заголовок должен быть отправлен

например, в будущем вам может понадобиться написать клиент-оболочку (не веб-браузер), который будет просто аутентифицировать себя только путем запроса заголовков страниц, а не всей HTML-кода

вы можете реализовать свое приложение для входа в систему обоими методами, используя ту же базу данных, что и список пользователей