Чи потрібно повернути код статусу 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 йдеться про те, що "[а] уторизація не допоможе", це слід розуміти ІМО в контексті як посилання на аутентифікацію RFC 2617 або подібні механізми авторизації на рівні протоколу; що стосується браузера, він не має уявлення, чи подання форми та отримання файлу cookie у відповідь вважається "авторизацією" чи чимось іншим.

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

У будь-якому випадку, якщо ви використовуєте файли cookie HTTP для зберігання маркерів аутентифікації після входу, вам слід включити заголовок Vary у відповіді (як до, так і після аутентифікації), щоб запобігти невідповідному кешування, як у Vary: Cookie.

По-перше, якщо для сторінки потрібен логін, то, ймовірно, слід заблокувати її robots.txt

По-друге, якщо роботи дійдуть на сторінку, помилка 401 є правильною.

Можливо, коди статусу можуть бути корисними для людей, які не належать до людини [та для деяких браузерів? ]

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

наприклад, у майбутньому вам може знадобитися написати клієнт-обгортку (а не веб-браузер), який просто автентифікує себе лише шляхом запиту заголовків сторінки, а не сукупності коду html

ви можете реалізувати свою програму входу за допомогою обох методів, використовуючи ту саму базу даних, що і список користувачів