HTTP 401 - ค่าส่วนหัว WWW-Authenticate ที่เหมาะสมคืออะไร


109

แอปพลิเคชันที่ฉันกำลังดำเนินการอยู่ในขณะนี้มีค่าระยะหมดเวลาของเซสชัน หากผู้ใช้ไม่ได้โต้ตอบนานกว่าค่านี้หน้าถัดไปที่พยายามโหลดผู้ใช้จะได้รับแจ้งให้เข้าสู่ระบบ

คำขอทั้งหมดจะถูกกำหนดเส้นทางผ่านกลไกนี้ซึ่งรวมถึงการโทร AJAX เดิมทีเรากำลังส่งส่วนหัว 200 พร้อมกับหน้าเข้าสู่ระบบซึ่งทำให้เกิดปัญหาบางอย่างกับ AJAX เนื่องจากมีการเรียกใช้โค้ดหากมีการส่งการตอบกลับ 200 ครั้งและข้อมูลส่วนใหญ่ที่ส่งกลับจากการเรียก RPC เหล่านี้คือ JSON หรือ JavaScript ดิบที่ได้รับการประเมิน (อย่า ถาม: |).

ฉันแนะนำว่า 401 ดีกว่าเนื่องจากตัวแยกวิเคราะห์ JSON ของเราจะไม่พยายามใช้หน้าล็อกอิน HTML .. :)

อย่างไรก็ตามเมื่ออ่านสเป็คฉันสังเกตว่าWWW-Authenticateต้องส่งฟิลด์ด้วย

ค่าที่ดีสำหรับสนามนี้คืออะไร? จะApplication Loginพอเพียง?

คำตอบ:


67

เมื่อระบุ HTTP Basic Authentication เราจะส่งคืนสิ่งที่ต้องการ:

WWW-Authenticate: Basic realm="myRealm"

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

เห็นได้ชัดว่าคุณไม่ได้ใช้ Basic อย่างไรก็ตามเนื่องจากไม่มีจุดที่เซสชันหมดอายุเมื่อใช้ Basic Auth ฉันถือว่าคุณกำลังใช้การตรวจสอบสิทธิ์ตามฟอร์มบางรูปแบบ

จากความทรงจำ Windows Challenge Response ใช้รูปแบบที่แตกต่างกันและอาร์กิวเมนต์ที่แตกต่างกัน

เคล็ดลับคือมันขึ้นอยู่กับเบราว์เซอร์ที่จะกำหนดว่ารองรับโครงร่างอะไรและตอบสนองอย่างไร

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

สำหรับประสบการณ์ User + AJAX ที่ดีจริง ๆ ให้รับสคริปต์เพื่อเชื่อมต่อกับคำขอ AJAX ที่พบว่าเซสชันหมดอายุเริ่มการร้องขอการเข้าสู่ระบบใหม่ผ่านป๊อปอัปและเมื่อประสบความสำเร็จให้ส่งคำขอ AJAX เดิมอีกครั้งและดำเนินการต่อตามปกติ

หลีกเลี่ยงการโกงที่เพิ่งได้รับสคริปต์ไปยังไซต์ทุกๆ 5 นาทีเพื่อให้เซสชันมีชีวิตอยู่เพราะเพิ่งเอาชนะจุดหมดอายุของเซสชัน

ทางเลือกอื่นคือเบิร์นคำขอ AJAX แต่นั่นเป็นประสบการณ์ของผู้ใช้ที่ไม่ดี


2
ขอบคุณเพื่อนตอนนี้ฉันใช้ 403 แทนเนื่องจากไม่ใช่การเปลี่ยนเส้นทางและมีแบบฟอร์มการเข้าสู่ระบบแทนที่หน้าเดิมอย่างแท้จริง นอกจากนี้ยังตรงกับข้อกำหนด W3 ได้ดีกว่า ขอบคุณสำหรับข้อมูลอย่างไรก็ตาม
Will Morgan

2
ดูคำตอบเกี่ยวกับวิธีที่คุณยังสามารถใช้ HTTP 401: stackoverflow.com/questions/928874/…
lanoxx

ใช่เพียงแค่ใส่อะไรก็ได้ในส่วนหัว WWW-Authenticate ฉันคิดว่า คำตอบอื่นในหลอดเลือดดำที่คล้ายกันคือstackoverflow.com/a/1088127/689161หรือเพียงแค่ละเมิดข้อมูลจำเพาะและไม่ต้องกังวลกับการส่งส่วนหัว (อย่างน้อยก็มีบางไซต์ที่ทำเช่นนี้) 401 ยังเหมาะสมกว่า 403
gengkev

ฉันไม่แน่ใจว่าจะ "ใส่อะไรก็ได้" ในส่วนหัว WWW-Authenticate เพราะฉันไม่แน่ใจว่า ajax หรือเบราว์เซอร์ของฉันจัดการคำขอหรือไม่ นอกเหนือจากชื่อของคำถามนี้แล้วเนื่องจากรายละเอียดที่แนะนำการพิสูจน์ตัวตนตามแบบฟอร์มฉันจะไม่ส่งส่วนหัว WWW-Authenticate เลย นี่เป็นเพราะฉันไม่ได้ขอให้เบราว์เซอร์เข้าร่วมในการตรวจสอบสิทธิ์ / ข้อมูลรับรอง ฉันแค่ต้องการให้มันแสดงฟอร์มที่เพิ่งเกิดขึ้นเป็นแบบฟอร์มการเข้าสู่ระบบ แต่ด้วยสิ่งที่ ajax สามารถใช้เพื่อระบุได้ว่าเป็นรูปแบบการเข้าสู่ระบบเพื่อให้สามารถจัดการกับมันได้แตกต่างจากข้างต้น
Swanny

คุณควรสร้างโครงร่าง authn เพื่อใช้กับส่วนหัว จากนั้นเบราว์เซอร์จะไม่เข้ามาเกี่ยวข้องเพราะไม่เข้าใจโครงร่าง ลูกค้าบางรายไม่พอใจหรือสับสนหากคุณไม่รวมส่วนหัว
KayEss

7

ไม่ได้คุณจะต้องระบุวิธีการตรวจสอบสิทธิ์ที่จะใช้ (โดยทั่วไปคือ "พื้นฐาน") และขอบเขตการตรวจสอบสิทธิ์ โปรดดูhttp://en.wikipedia.org/wiki/Basic_access_authenticationสำหรับคำขอและการตอบกลับตัวอย่าง

นอกจากนี้คุณยังอาจต้องการอ่านRFC 2617 - HTTP รับรองความถูกต้อง: Basic และ Digest ตรวจสอบการเข้าถึง


-7

เมื่อเซสชันผู้ใช้หมดเวลาฉันจะส่งรหัสสถานะ HTTP 204 กลับไป โปรดทราบว่าสถานะ HTTP 204 ไม่มีเนื้อหา ในฝั่งไคลเอ็นต์ฉันทำสิ่งนี้:

xhr.send(null);
if (xhr.status == 204) 
    Reload();
else 
    dropdown.innerHTML = xhr.responseText;

นี่คือฟังก์ชั่น Reload ():

function Reload() {
    var oForm = document.createElement("form");
    document.body.appendChild(oForm);
    oForm.submit();
    }

6
ทำไมคุณถึงใช้ HTTP 204? developer.mozilla.org/en-US/docs/Web/HTTP/Status/204
Will Morgan
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.