Haruskah saya mengembalikan kode status http 401 pada formulir masuk berbasis html?

Haruskah saya mengembalikan kode status http 401 pada formulir masuk berbasis html? Halaman ini adalah formulir login khusus, dan tidak memiliki konten bermakna lainnya, hanya kerangka kerja situs. Namun URL, bisa untuk halaman yang memang memiliki konten yang bermakna, tetapi membutuhkan login. Perhatikan bahwa pengaturan ini hanya mengembalikan kode status 401, dan tidak meminta pengguna untuk otentikasi dasar.

Melihat standar tampaknya 401 adalah kode status yang tidak pantas untuk formulir masuk berbasis html. Namun, saya tidak pernah mengalami atau mendengar konsekuensi buruk dari melakukannya.

Saat mengirim 401, "Respons HARUS menyertakan bidang tajuk WWW-Otentikasi (bagian 14.47) yang berisi tantangan yang berlaku untuk sumber daya yang diminta."

persyaratan yang disebutkan di sini:

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

dirinci di sini:

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

Saya tahu ada beberapa cara yang dapat saya lakukan di sekitar mesin pencari dalam meyakinkan mereka untuk mengindeks, atau tidak, halaman berdasarkan keberadaan formulir login, tapi saya lebih suka menggunakan kode status http, khususnya 401 karena definisi itu sepertinya seperti pasangan yang sempurna jika bukan karena persyaratan tajuk WWW-Authenticate.

Apakah ada alasan mengapa saya tidak menggunakan 401 dalam kasus ini? Secara semantik apakah ada perbedaan antara tidak diotorisasi pada level http versus diotorisasi pada level aplikasi? Jelas Anda dapat memiliki keduanya, tetapi bukankah otentikasi di tingkat http hanya untuk kemudahan tidak menerapkannya di tingkat aplikasi?

Seperti yang Anda perhatikan, RFC 2616 mensyaratkan bahwa respons 401 disertai oleh header RFC 2617 WWW-Authenticate. Saya kira Anda secara teknis dapat memenuhi persyaratan itu dengan mengirim tajuk palsu seperti:

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

tapi saya tidak tahu browser apa yang akan dilakukan jika disajikan dengan respons 401 yang tidak mengandung tantangan yang mereka pahami. Saya akan berasumsi bahwa sebagian besar jika tidak semua dari mereka akan menyajikan tubuh permintaan kepada pengguna (seperti RFC 2616 mengatakan mereka harus melakukan jika otentikasi gagal), tetapi RFC tampaknya tidak mengatakannya secara eksplisit, sehingga mereka mungkin secara sah hanya menampilkan pesan kesalahan umum sebagai gantinya.

Alternatif yang mungkin (jika Anda tidak ingin hanya menggunakan 200 respons seperti yang dilakukan orang lain) adalah menggunakan 403 kode status Terlarang . Ini adalah kode respons yang banyak digunakan, dan sejauh yang saya tahu, hampir semua agen pengguna interaktif (yaitu browser, sebagai lawan dari, katakanlah, mesin pencari atau pengelola unduhan) harus bereaksi terhadapnya dengan menyajikan konten kepada pengguna, setidaknya apakah itu cukup panjang .

Meskipun deskripsi kode status 403 mengatakan bahwa "[a] ucapan tidak akan membantu", ini harus IMO dipahami dalam konteks yang merujuk pada otentikasi RFC 2617 atau mekanisme otorisasi tingkat protokol serupa; sejauh menyangkut browser, ia tidak tahu apakah mengirimkan formulir dan menerima cookie dalam tanggapan dianggap sebagai "otorisasi" atau sesuatu yang lain.

Satu mekanisme yang lebih umum digunakan adalah menanggapi permintaan yang tidak diautentikasi dengan pengalihan sementara ke halaman login yang terpisah, dengan URL asli diteruskan sebagai parameter sehingga pengguna dapat diarahkan kembali ke sana setelah otentikasi berhasil. Namun, perhatikan bahwa penerapan naif dapat memungkinkan orang jahat untuk membuat tautan masuk yang akan mengarahkan pengguna ke URL sewenang-wenang setelah masuk. Jika ini bisa menjadi masalah keamanan, Anda harus mengambil langkah-langkah untuk mencegahnya, misalnya dengan hanya menerima mengembalikan URL yang cocok dengan pola aman yang diketahui, atau dengan melindungi URL kembali dengan kode otentikasi pesan untuk mencegah modifikasi.

Dalam kasus apa pun, jika Anda menggunakan cookie HTTP untuk menyimpan token otentikasi setelah login, Anda harus menyertakan header yang bervariasi dalam respons Anda (baik sebelum dan sesudah otentikasi) untuk mencegah caching yang tidak sesuai, seperti pada Vary: Cookie.

Pertama, jika halaman tersebut perlu login, maka Anda mungkin harus memblokirnya dengan robots.txt

Kedua, jika robot mencapai halaman, kesalahan 401 tepat.

mungkin, kode status dapat berguna untuk non-manusia [dan untuk beberapa browser? ]

secara independen dengan metode login, tajuk yang benar harus dikirim

misalnya di masa mendatang Anda mungkin perlu menulis klien pembungkus (bukan browser web) yang hanya akan mengautentikasi dirinya sendiri hanya dengan meminta header halaman, bukan totalitas kode html

Anda dapat mengimplementasikan aplikasi login Anda dengan kedua metode menggunakan database yang sama dengan daftar pengguna