ฉันควรส่งคืนรหัสสถานะ 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 พร้อมกับส่วนหัวของ WWW-Authenticate RFC 2617 ฉันคิดว่าคุณสามารถปฏิบัติตามข้อกำหนดทางเทคนิคได้โดยส่งหัวข้อปลอมเช่น:

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

แต่ฉันไม่รู้ว่าเบราว์เซอร์จะทำอะไรถ้ามีการตอบสนอง 401 ซึ่งไม่มีความท้าทายที่พวกเขาเข้าใจ ฉันจะสมมติว่าส่วนใหญ่หากไม่ใช่ทั้งหมดของพวกเขาจะนำเสนอเนื้อหาคำขอให้กับผู้ใช้ (ตามที่ RFC 2616 บอกว่าพวกเขาควรทำอย่างไรหากการตรวจสอบสิทธิ์ล้มเหลว) แต่ RFC ดูเหมือนจะไม่พูดอย่างชัดเจนดังนั้นพวกเขาอาจแสดงข้อความผิดพลาดทั่วไป แทน.

ทางเลือกอื่นที่เป็นไปได้ (ถ้าคุณไม่ต้องการเพียงแค่ใช้การตอบสนอง 200 แบบที่คนอื่นทำ) จะใช้รหัสสถานะ403 ที่ต้องห้าม นี่เป็นรหัสการตอบสนองที่ใช้กันอย่างแพร่หลายและเท่าที่ฉันทราบตัวแทนผู้ใช้แบบโต้ตอบเกือบทั้งหมด (เช่นเบราว์เซอร์ซึ่งตรงกันข้ามกับการพูดเครื่องมือค้นหาหรือตัวจัดการดาวน์โหลด) ควรตอบสนองโดยนำเสนอเนื้อหาให้กับผู้ใช้อย่างน้อย ถ้ามันนานพอ

แม้ว่าคำอธิบายของรหัสสถานะ 403 บอกว่า "การใช้ uthorization จะไม่ช่วย" แต่ควรเข้าใจ IMO นี้ในบริบทที่อ้างถึงการรับรองความถูกต้อง RFC 2617 หรือกลไกการอนุญาตระดับโปรโตคอลที่คล้ายกัน เท่าที่เบราว์เซอร์มีความกังวลก็ไม่มีความคิดว่าการส่งแบบฟอร์มและรับคุกกี้ในการตอบสนองนับเป็น "การอนุญาต" หรืออย่างอื่น

กลไกที่ใช้กันมากกว่าหนึ่งอย่างคือการตอบสนองต่อคำขอที่ไม่ได้รับการรับรองความถูกต้องด้วยการเปลี่ยนเส้นทางชั่วคราวไปยังหน้าเข้าสู่ระบบแยกต่างหากโดยมี URL ดั้งเดิมส่งผ่านเป็นพารามิเตอร์เพื่อให้ผู้ใช้สามารถเปลี่ยนเส้นทางกลับไปได้ อย่างไรก็ตามโปรดทราบว่าการใช้งานแบบไร้เดียงสาอาจอนุญาตให้บุคคลที่ประสงค์ร้ายสร้างลิงก์การเข้าสู่ระบบที่จะเปลี่ยนเส้นทางผู้ใช้ไปยัง URL ที่กำหนดเองหลังจากเข้าสู่ระบบหากนี่อาจเป็นปัญหาด้านความปลอดภัยคุณควรดำเนินการเพื่อป้องกัน ส่งคืน URL ที่ตรงกับรูปแบบที่ปลอดภัยที่รู้จักหรือปกป้อง URL ที่ส่งคืนด้วยรหัสการตรวจสอบข้อความเพื่อป้องกันการแก้ไข

ในกรณีใด ๆ หากคุณกำลังใช้ HTTP คุกกี้เพื่อสัญญาณการตรวจสอบการจัดเก็บหลังจากเข้าสู่ระบบคุณควรจะมีแตกต่างกันไปส่วนหัวในคำตอบของคุณ (ทั้งก่อนและหลังการตรวจสอบ) Vary: Cookieเพื่อป้องกันการแคชที่ไม่เหมาะสมเช่นเดียวกับใน

ก่อนอื่นหากหน้านั้นต้องการล็อกอินคุณควรบล็อกโดย robots.txt

ประการที่สองหากโรบอตเข้าถึงหน้านั้นข้อผิดพลาด 401 นั้นถูกต้อง

เป็นไปได้ว่ารหัสสถานะอาจมีประโยชน์สำหรับผู้ที่ไม่ใช่มนุษย์ [และสำหรับบางเบราว์เซอร์? ]

อิสระโดยวิธีการเข้าสู่ระบบส่วนหัวที่ถูกต้องควรจะส่ง

ตัวอย่างเช่นในอนาคตคุณอาจต้องเขียนโปรแกรม wrapper (ไม่ใช่เว็บเบราว์เซอร์) ที่จะรับรองความถูกต้องของตัวเองโดยการขอส่วนหัวของหน้าเท่านั้นไม่ใช่ผลรวมของรหัส html

คุณสามารถใช้แอปพลิเคชั่นเข้าสู่ระบบด้วยทั้งสองวิธีโดยใช้ฐานข้อมูลเดียวกับรายชื่อผู้ใช้