สำหรับหน้าเว็บที่มีอยู่ แต่ผู้ใช้ไม่มีสิทธิ์เพียงพอ (ไม่ได้ล็อกอินหรือไม่ได้อยู่ในกลุ่มผู้ใช้ที่เหมาะสม) การตอบสนอง HTTP ที่เหมาะสมในการแสดงคืออะไร?

401 Unauthorized?
403 Forbidden?
อื่น ๆ อีก?

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

คำอธิบายที่ชัดเจนจากDaniel Irvine :

มีปัญหากับ401 Unauthorized , รหัสสถานะ HTTP สำหรับข้อผิดพลาดในการตรวจสอบสิทธิ์ และนั่นเป็นเพียง: สำหรับการรับรองความถูกต้องไม่ได้รับอนุญาต การรับการตอบกลับ 401 เป็นเซิร์ฟเวอร์ที่บอกคุณว่า“ คุณไม่ได้รับการรับรองความถูกต้อง - ไม่ได้รับการรับรองความถูกต้องทั้งหมดหรือรับรองความถูกต้องไม่ถูกต้อง - แต่โปรดตรวจสอบสิทธิ์อีกครั้งแล้วลองอีกครั้ง " เพื่อช่วยให้คุณมีส่วนหัวWWW-Authenticateที่อธิบายวิธีการตรวจสอบสิทธิ์เสมอ

นี่เป็นคำตอบที่เว็บเซิร์ฟเวอร์ของคุณส่งกลับไม่ใช่เว็บแอปพลิเคชันของคุณ

มันเป็นอะไรที่ชั่วคราวมาก เซิร์ฟเวอร์ขอให้คุณลองอีกครั้ง

ดังนั้นสำหรับการให้สิทธิ์ฉันใช้403 Forbidden response มันถาวรมันเชื่อมโยงกับตรรกะแอปพลิเคชันของฉันและเป็นการตอบสนองที่เป็นรูปธรรมมากกว่า 401

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

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

อีกรูปแบบภาพที่ดีของวิธีการใช้รหัสสถานะ http

ดูRFC2616 :

401 ไม่ได้รับอนุญาต:

หากคำร้องขอนั้นมีข้อมูลประจำตัวการอนุญาตแล้วการตอบสนอง 401 บ่งชี้ว่าการอนุญาตนั้นถูกปฏิเสธสำหรับข้อมูลรับรองเหล่านั้น

403 ต้องห้าม:

เซิร์ฟเวอร์เข้าใจคำขอ แต่ปฏิเสธที่จะปฏิบัติตาม

ปรับปรุง

จากกรณีการใช้งานของคุณปรากฏว่าผู้ใช้ไม่ได้รับการตรวจสอบความถูกต้อง ฉันจะกลับ 401

แก้ไข: RFC2616เป็นล้าสมัยดูRFC7231และRFC7235

สิ่งที่คำตอบอื่น ๆ หายไปคือต้องเข้าใจว่าการรับรองความถูกต้องและการอนุญาตในบริบทของ RFC 2616 อ้างถึงโปรโตคอล HTTP Authentication ของ RFC 2617 เท่านั้นการรับรองความถูกต้องโดยแบบแผนภายนอกของ RFC2617 ไม่ได้รับการสนับสนุนในรหัสสถานะ HTTP และไม่พิจารณา เมื่อตัดสินใจว่าจะใช้ 401 หรือ 403

บทสรุปและ Terse

ไม่ได้รับอนุญาตระบุว่าลูกค้าไม่ได้รับการรับรองความถูกต้องของ RFC2617 และเซิร์ฟเวอร์กำลังเริ่มกระบวนการตรวจสอบสิทธิ์ ห้ามระบุว่าไคลเอ็นต์นั้นได้รับการรับรองความถูกต้องของ RFC2617 และไม่ได้รับอนุญาตหรือเซิร์ฟเวอร์ไม่รองรับ RFC2617 สำหรับทรัพยากรที่ร้องขอ

หมายความว่าหากคุณมีกระบวนการเข้าสู่ระบบของคุณเองและไม่เคยใช้การรับรองความถูกต้องของ HTTP 403 เป็นคำตอบที่เหมาะสมเสมอและไม่ควรใช้ 401

รายละเอียดและในเชิงลึก

จาก RFC2616

10.4.2 401 ไม่ได้รับอนุญาต

คำขอต้องมีการตรวจสอบผู้ใช้ การตอบสนองต้องมีฟิลด์ส่วนหัว WWW-Authenticate (ส่วน 14.47) ที่มีความท้าทายที่เกี่ยวข้องกับทรัพยากรที่ร้องขอ ไคลเอนต์อาจทำซ้ำการร้องขอด้วยฟิลด์หัวข้อการอนุญาตที่เหมาะสม (ส่วน 14.8)

และ

10.4.4 403 ต้องห้ามเซิร์ฟเวอร์เข้าใจคำขอ แต่ปฏิเสธที่จะทำตาม การอนุญาตจะไม่ช่วยและคำขอจะไม่ถูกทำซ้ำ

สิ่งแรกที่ต้องจำไว้คือ "การรับรองความถูกต้อง" และ "การอนุญาต" ในบริบทของเอกสารนี้อ้างอิงถึงโปรโตคอล HTTP Authentication จาก RFC 2617 โดยเฉพาะพวกเขาไม่ได้อ้างถึงโปรโตคอลการตรวจสอบสิทธิ์แบบม้วนของคุณเองที่คุณอาจสร้างขึ้น ใช้หน้าเข้าสู่ระบบ ฯลฯ ฉันจะใช้ "เข้าสู่ระบบ" เพื่ออ้างถึงการตรวจสอบและการอนุญาตโดยวิธีการอื่นนอกเหนือจาก RFC2617

ดังนั้นความแตกต่างที่แท้จริงไม่ใช่ปัญหาหรือแม้ว่าจะมีทางออกก็ตาม ความแตกต่างคือสิ่งที่เซิร์ฟเวอร์คาดหวังให้ลูกค้าทำต่อไป

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

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

แก้ไข: RFC2616เป็นล้าสมัยดูRFC7231และRFC7235

  + -----------------------
  | มีทรัพยากรออกมา? (ถ้าเป็นส่วนตัวก็มักจะตรวจสอบหลังจากตรวจสอบรับรองความถูกต้อง)
  + -----------------------
    | |
 ไม่ v ใช่
    v + -----------------------
   404 | เข้าสู่ระบบหรือไม่ (รับรองความถูกต้อง, aka มีเซสชันหรือคุกกี้ JWT)
   หรือ + -----------------------
   401 | |
   403 NO | | ใช่
   3xx vv
              401 + -----------------------
       (404 ไม่เปิดเผย) สามารถเข้าถึงทรัพยากรได้หรือไม่ (การอนุญาต, ผู้มีอำนาจ, ... )
              หรือ + -----------------------
             เปลี่ยนเส้นทาง | |
             เพื่อเข้าสู่ระบบ NO | | ใช่
                               | |
                               VV
                               403 ตกลง 200 เปลี่ยนเส้นทาง ...
                      (หรือ 404: ไม่เปิดเผย)
                      (หรือ 404: ทรัพยากรไม่มีอยู่ถ้าเป็นส่วนตัว)
                      (หรือ 3xx: การเปลี่ยนเส้นทาง)

เช็คมักจะทำตามคำสั่งนี้:

• 404 ถ้าทรัพยากรเป็นสาธารณะและไม่มีอยู่หรือเปลี่ยนเส้นทาง 3xx
• มิฉะนั้น:
• 401 ถ้าไม่ได้เข้าสู่ระบบหรือเซสชันหมดอายุ
• 403 หากผู้ใช้ไม่ได้รับอนุญาตให้เข้าถึงทรัพยากร (ไฟล์, json, ... )
• 404 ถ้าทรัพยากรไม่มีอยู่หรือไม่เต็มใจเปิดเผยอะไรเลยหรือเปลี่ยนเส้นทาง 3xx

ไม่ได้รับอนุญาต : รหัสสถานะ (401) ที่ระบุว่าคำขอต้องการการรับรองความถูกต้องซึ่งปกติหมายถึงผู้ใช้จำเป็นต้องเข้าสู่ระบบ (เซสชัน) ผู้ใช้ / ตัวแทนไม่รู้จักโดยเซิร์ฟเวอร์ สามารถทำซ้ำกับข้อมูลประจำตัวอื่น ๆ หมายเหตุ: สิ่งนี้ทำให้เกิดความสับสนเนื่องจากควรมีชื่อ 'ไม่ได้รับการรับรองความถูกต้อง' แทน 'ไม่ได้รับอนุญาต' สิ่งนี้สามารถเกิดขึ้นได้หลังจากเข้าสู่ระบบหากเซสชันหมดอายุ กรณีพิเศษ: สามารถใช้แทน 404 เพื่อหลีกเลี่ยงการแสดงตนหรือไม่ปรากฏตัวของทรัพยากร (สินเชื่อ @gingerCodeNinja)

FORBIDDEN : รหัสสถานะ (403) ที่ระบุว่าเซิร์ฟเวอร์เข้าใจคำขอ แต่ปฏิเสธที่จะปฏิบัติตาม ผู้ใช้ / ตัวแทนที่รู้จักกันโดยเซิร์ฟเวอร์ แต่มีข้อมูลประจำตัวที่ไม่เพียงพอ คำขอทำซ้ำจะไม่ทำงานจนกว่าข้อมูลรับรองจะเปลี่ยนแปลงซึ่งไม่น่าเป็นไปได้มากในช่วงเวลาสั้น ๆ กรณีพิเศษ: สามารถใช้แทน 404 เพื่อหลีกเลี่ยงการแสดงตนหรือไม่ปรากฏตัวของทรัพยากร (สินเชื่อ @gingerCodeNinja)

ไม่พบ : รหัสสถานะ (404) ระบุว่าทรัพยากรที่ร้องขอไม่สามารถใช้ได้ รู้จักผู้ใช้ / เอเจนต์ แต่เซิร์ฟเวอร์จะไม่เปิดเผยอะไรเกี่ยวกับทรัพยากรทำราวกับว่าไม่มีอยู่ การทำซ้ำจะไม่ทำงาน นี่คือการใช้งานพิเศษ 404 (ตัวอย่างเช่น GitHub)

ดังที่ @ChrisH มีตัวเลือกสำหรับการเปลี่ยนเส้นทาง 3xx (301, 302, 303, 307 หรือไม่เปลี่ยนเส้นทางเลยและใช้ 401):

• ความแตกต่างระหว่างรหัสการเปลี่ยนเส้นทาง HTTP
• เบราว์เซอร์ทำแคช HTTP 301s นานเท่าใด
• รหัสสถานะ HTTP ที่ถูกต้องคืออะไรเมื่อเปลี่ยนเส้นทางไปยังหน้าเข้าสู่ระบบ
• ความแตกต่างระหว่างการเปลี่ยนเส้นทาง 302 และ 307 คืออะไร

ตามRFC 2616 (HTTP / 1.1) 403 จะถูกส่งเมื่อ:

เซิร์ฟเวอร์เข้าใจคำขอ แต่ปฏิเสธที่จะปฏิบัติตาม การอนุญาตจะไม่ช่วยและคำขอจะไม่ถูกทำซ้ำ หากวิธีการร้องขอไม่ได้เป็น HEAD และเซิร์ฟเวอร์ประสงค์ที่จะเปิดเผยต่อสาธารณะว่าทำไมคำขอไม่ได้รับการตอบสนองก็ควรอธิบายถึงเหตุผลในการปฏิเสธในเอนทิตี หากเซิร์ฟเวอร์ไม่ต้องการให้ข้อมูลนี้พร้อมใช้งานสำหรับลูกค้าสามารถใช้รหัสสถานะ 404 (ไม่พบ) แทน

กล่าวอีกนัยหนึ่งหากลูกค้าสามารถเข้าถึงทรัพยากรโดยการตรวจสอบสิทธิ์ควรส่ง 401

สมมติว่า HTTP รับรองความถูกต้อง ( WWW-Authenticateและการอนุญาตส่วนหัว) ที่อยู่ในการใช้งานหากตรวจสอบเป็นผู้ใช้อื่นจะให้สิทธิ์การเข้าถึงทรัพยากรที่ร้องขอแล้ว 401 ไม่ได้รับอนุญาตจะถูกส่งกลับ

403 ต้องห้ามถูกใช้เมื่อทุกคนเข้าถึงทรัพยากรต้องห้ามหรือ จำกัด เครือข่ายที่กำหนดหรืออนุญาตผ่าน SSL เท่านั้นไม่ว่าจะเกี่ยวข้องกับการตรวจสอบสิทธิ์ HTTP หรือไม่ก็ตาม

หากไม่ได้ใช้การตรวจสอบความถูกต้องของ HTTPและให้บริการรูปแบบการตรวจสอบความถูกต้องของคุกกี้ตามปกติในปัจจุบันดังนั้นควรส่งคืน 403 หรือ 404

เกี่ยวกับ 401 นี่มาจาก RFC 7235 (Hypertext Transfer Protocol (HTTP / 1.1): การรับรองความถูกต้อง):

3.1 401 ไม่ได้รับอนุญาต

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

ความหมายของ 403 (และ 404) มีการเปลี่ยนแปลงเมื่อเวลาผ่านไป นี่คือจากปี 1999 (RFC 2616):

10.4.4 403 สิ่งต้องห้าม

เซิร์ฟเวอร์เข้าใจคำขอ แต่ปฏิเสธที่จะปฏิบัติตาม
การอนุญาตจะไม่ช่วยและไม่ควรทำซ้ำการร้องขอ
หากวิธีการร้องขอไม่ได้เป็น HEAD และเซิร์ฟเวอร์ประสงค์ที่จะ
เปิดเผยต่อสาธารณะว่าทำไมคำขอไม่ได้รับการตอบสนองก็ควรอธิบายถึงเหตุผลในการปฏิเสธในเอนทิตี หากเซิร์ฟเวอร์ไม่ต้องการให้ข้อมูลนี้พร้อมใช้งานสำหรับลูกค้าสามารถใช้รหัสสถานะ 404
(ไม่พบ) แทน

ในปี 2014 RFC 7231 (Hypertext Transfer Protocol (HTTP / 1.1): ความหมายและเนื้อหา) เปลี่ยนความหมายของ 403:

6.5.3 403 ต้องห้าม

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

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

เซิร์ฟเวอร์ต้นทางที่ต้องการ "ซ่อน" การมีอยู่ของ
ทรัพยากรเป้าหมายต้องห้ามในปัจจุบันอาจตอบกลับด้วยรหัสสถานะ
404 (ไม่พบ)

ดังนั้นตอนนี้ 403 (หรือ 404) อาจหมายถึงอะไรก็ได้ การให้ข้อมูลประจำตัวใหม่อาจช่วย ... หรืออาจจะไม่

ฉันเชื่อว่าเหตุผลที่ทำให้สิ่งนี้เปลี่ยนไปคือ RFC 2616 สันนิษฐานว่าการรับรองความถูกต้อง HTTP จะใช้เมื่อในทางปฏิบัติเว็บแอปในปัจจุบันสร้างโครงร่างการรับรองความถูกต้องที่กำหนดเองโดยใช้ตัวอย่างเช่นฟอร์มและคุกกี้

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

OWASP มีข้อมูลเพิ่มเติมเกี่ยวกับวิธีที่ผู้โจมตีสามารถใช้ข้อมูลประเภทนี้เป็นส่วนหนึ่งของการโจมตี

• 401 ไม่ได้รับอนุญาต : ฉันไม่รู้ว่าคุณเป็นใคร นี่เป็นข้อผิดพลาดการรับรองความถูกต้อง
• 403 ห้าม : ฉันรู้ว่าคุณเป็นใคร แต่คุณไม่ได้รับอนุญาตให้เข้าถึงทรัพยากรนี้ นี่เป็นข้อผิดพลาดการอนุญาต

คำถามนี้ถูกถามเมื่อไม่นานมานี้ แต่ความคิดของผู้คนกำลังดำเนินต่อไป

มาตรา 6.5.3ในร่างนี้ (ประพันธ์โดยฟีลดิงและ Reschke) ให้รหัสสถานะ 403 มีความหมายแตกต่างกันเล็กน้อยกับที่บันทึกไว้ในRFC 2616

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

ฉันเน้นสิ่งที่ฉันคิดว่าสำคัญที่สุด

6.5.3 403 ต้องห้าม

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

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

เซิร์ฟเวอร์ต้นทางที่ต้องการ "ซ่อน" การมีอยู่ของทรัพยากรเป้าหมายต้องห้ามในปัจจุบันอาจตอบกลับด้วยรหัสสถานะ 404 (ไม่พบ)

สิ่งที่คุณใช้ในการประชุมสิ่งสำคัญคือการให้ความเท่าเทียมกันทั่วทั้งไซต์ / API ของคุณ

TL; DR

• 401: การปฏิเสธที่เกี่ยวข้องกับการรับรองความถูกต้อง
• 403: การปฏิเสธที่ไม่มีส่วนเกี่ยวข้องกับการรับรองความถูกต้อง

ตัวอย่างการปฏิบัติ

หากapache ต้องการการรับรองความถูกต้อง (ผ่าน.htaccess) และคุณกดCancelมันจะตอบสนองด้วย401 Authorization Required

หากnginxค้นหาไฟล์ แต่ไม่มีสิทธิ์การเข้าถึง (ผู้ใช้ / กลุ่ม) เพื่ออ่าน / เข้าถึงไฟล์จะตอบกลับด้วย403 Forbidden

RFC (2616 มาตรา 10)

401 ไม่ได้รับอนุญาต (10.4.2)

ความหมายที่ 1: จำเป็นต้องตรวจสอบ

คำขอต้องมีการตรวจสอบผู้ใช้ ...

ความหมายที่ 2: การรับรองความถูกต้องไม่เพียงพอ

... หากคำร้องขอนั้นมีข้อมูลประจำตัวการอนุญาตแล้วการตอบกลับ 401 บ่งชี้ว่าการอนุญาตนั้นถูกปฏิเสธสำหรับข้อมูลรับรองเหล่านั้น ...

403 ต้องห้าม (10.4.4)

ความหมาย: ไม่เกี่ยวข้องกับการรับรองความถูกต้อง

... การอนุญาตจะไม่ช่วย ...

รายละเอียดเพิ่มเติม:

• เซิร์ฟเวอร์เข้าใจคำขอ แต่ปฏิเสธที่จะปฏิบัติตาม

• มันควรอธิบายถึงสาเหตุของการปฏิเสธในเอนทิตี

• รหัสสถานะ 404 (ไม่พบ) สามารถใช้แทนได้

  (หากเซิร์ฟเวอร์ต้องการเก็บข้อมูลนี้จากลูกค้า)

พวกเขาไม่ได้เข้าสู่ระบบหรือไม่ได้อยู่ในกลุ่มผู้ใช้ที่เหมาะสม

คุณระบุสองกรณีที่แตกต่างกัน แต่ละกรณีควรมีการตอบสนองที่แตกต่างกัน:

1. หากพวกเขาไม่ได้เข้าสู่ระบบเลยคุณควรกลับ401 ไม่ได้รับอนุญาต
2. หากพวกเขาเข้าสู่ระบบ แต่ไม่ได้อยู่ในกลุ่มผู้ใช้ที่เหมาะสมคุณควรส่งคืน403 สิ่งต้องห้าม

หมายเหตุเกี่ยวกับ RFC ตามความคิดเห็นที่ได้รับจากคำตอบนี้:

หากผู้ใช้ไม่ได้เข้าสู่ระบบพวกเขาจะไม่ได้รับการรับรองความถูกต้อง HTTP เทียบเท่าซึ่งเป็น 401 และเรียกว่าไม่ได้รับอนุญาตใน RFC ตามมาตรา 10.4.2ระบุว่า401 ไม่ได้รับอนุญาต :

"คำขอต้องมีการตรวจสอบสิทธิ์ผู้ใช้"

หากคุณไม่ได้รับการรับรองความถูกต้อง 401 คือคำตอบที่ถูกต้อง อย่างไรก็ตามหากคุณไม่ได้รับอนุญาตในความหมายที่ถูกต้องความหมาย 403 เป็นการตอบสนองที่ถูกต้อง

นี่คือความหมาย:

401 : รับรองความถูกต้องของผู้ใช้ไม่ถูกต้องทรัพยากร / หน้าต้องการการรับรองความถูกต้อง

403 : ผู้ใช้รับรองความถูกต้อง แต่บทบาทหรือสิทธิ์ของเขาไม่อนุญาตให้เข้าถึงทรัพยากรที่ร้องขอเช่นผู้ใช้ไม่ใช่ผู้ดูแลระบบและหน้าที่ร้องขอสำหรับผู้ดูแลระบบ

นี่ง่ายกว่าที่อื่นในหัวดังนั้น:

401: คุณต้องมีการตรวจสอบสิทธิ์พื้นฐาน HTTP เพื่อดูสิ่งนี้

403: คุณไม่เห็นสิ่งนี้และการตรวจสอบสิทธิ์พื้นฐาน HTTP จะไม่ช่วย

หากผู้ใช้เพียงแค่ต้องเข้าสู่ระบบโดยใช้แบบฟอร์มการเข้าสู่ระบบ HTML มาตรฐานของเว็บไซต์ของคุณ 401 จะไม่เหมาะสมเพราะมันเป็นเฉพาะกับ HTTP รับรองความถูกต้องขั้นพื้นฐาน

ฉันไม่แนะนำให้ใช้ 403 เพื่อปฏิเสธการเข้าถึงสิ่งต่าง ๆ เช่น /includesเดียวกับที่เกี่ยวข้องกับเว็บทรัพยากรเหล่านั้นไม่มีอยู่เลยและควรจะ 404

สิ่งนี้ทำให้ 403 เป็น "คุณต้องเข้าสู่ระบบ"

กล่าวอีกนัยหนึ่ง 403 หมายถึง "ทรัพยากรนี้ต้องการการรับรองความถูกต้องบางรูปแบบนอกเหนือจากการรับรองความถูกต้องพื้นฐาน HTTP"

https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2

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

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

• ทรัพยากรที่ต้องตรวจสอบ แต่ไม่มีข้อมูลประจำตัวที่ถูกระบุ

401 : ไคลเอนต์ควรระบุข้อมูลประจำตัว

• ข้อมูลประจำตัวที่ระบุอยู่ในรูปแบบที่ไม่ถูกต้อง

400 : ไม่ใช่ 401 หรือ 403 เนื่องจากข้อผิดพลาดทางไวยากรณ์ควรส่งคืน 400 เสมอ

• ข้อมูลประจำตัวที่ระบุอ้างอิงผู้ใช้ที่ไม่ได้อยู่

401 : ไคลเอ็นต์ควรระบุข้อมูลรับรองที่ถูกต้อง

• ที่ระบุข้อมูลประจำตัวที่มีความไม่ถูกต้องแต่ระบุเป็นผู้ใช้ที่ถูกต้อง (หรือไม่ได้ระบุผู้ใช้หากผู้ใช้ที่ระบุไม่จำเป็น)

401 : อีกครั้งไคลเอนต์ควรระบุข้อมูลประจำตัวที่ถูกต้อง

• ที่ระบุข้อมูลประจำตัวได้หมดอายุแล้ว

401 : นี่เป็นจริงเหมือนกับการมีข้อมูลประจำตัวที่ไม่ถูกต้องโดยทั่วไปดังนั้นลูกค้าควรระบุข้อมูลประจำตัวที่ถูกต้อง

• ข้อมูลประจำตัวที่ระบุนั้นถูกต้องสมบูรณ์ แต่ไม่พอเพียงกับทรัพยากรแม้ว่าจะเป็นไปได้ว่าข้อมูลรับรองที่มีสิทธิ์เพิ่มเติมสามารถทำได้

403 : การระบุข้อมูลรับรองที่ถูกต้องจะไม่ให้สิทธิ์การเข้าถึงทรัพยากรเนื่องจากข้อมูลรับรองปัจจุบันนั้นถูกต้องแล้ว แต่ไม่ได้รับอนุญาต

• โดยเฉพาะอย่างยิ่งทรัพยากรคือไม่สามารถเข้าถึงได้โดยไม่คำนึงถึงข้อมูลประจำตัว

403 : นี่คือไม่คำนึงถึงข้อมูลประจำตัวดังนั้นการระบุข้อมูลประจำตัวที่ถูกต้องไม่สามารถช่วยได้

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

403 : หากลูกค้าถูกบล็อคการระบุข้อมูลประจำตัวใหม่จะไม่ทำอะไรเลย

เป็นภาษาอังกฤษ:

401

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

403

คุณไม่ได้รับอนุญาต ชื่อของคุณไม่ได้อยู่ในรายชื่อคุณจะไม่เคยเข้าไปข้างในออกไปอย่าส่งคำขอให้ลองใหม่มันจะถูกปฏิเสธเสมอ ไปให้พ้น.

เมื่อพิจารณาจาก RFC ล่าสุดเกี่ยวกับเรื่อง ( 7231และ7235 ) กรณีการใช้งานนั้นค่อนข้างชัดเจน (เพิ่มตัวเอียง):

• 401 สำหรับการรับรองความถูกต้อง ("ขาดการตรวจสอบที่ถูกต้อง"); นั่นคือ 'ฉันไม่รู้ว่าคุณเป็นใครหรือไม่เชื่อใจคุณว่าคุณเป็นใคร'

401 ไม่ได้รับอนุญาต

รหัสสถานะ 401 (ไม่ได้รับอนุญาต) บ่งชี้ว่าคำขอไม่ได้ถูกนำไปใช้เพราะไม่มีการตรวจสอบที่ถูกต้องข้อมูลรับรองการสำหรับทรัพยากรเป้าหมาย เซิร์ฟเวอร์ที่สร้างการตอบสนอง 401 ต้องส่งฟิลด์ส่วนหัวรับรองความถูกต้อง WWW (ส่วน 4.1) ที่มีความท้าทายอย่างน้อยหนึ่งข้อที่เกี่ยวข้องกับทรัพยากรเป้าหมาย

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

• 403 สำหรับการไม่ได้รับอนุญาต ("ปฏิเสธการอนุญาต"); คือ 'ฉันรู้ว่าคุณเป็นใคร แต่คุณไม่ได้รับอนุญาตให้เข้าถึงทรัพยากรนี้'

403 ต้องห้าม

รหัสสถานะ 403 (ต้องห้าม) ระบุว่าเซิร์ฟเวอร์เข้าใจคำขอ แต่ปฏิเสธที่จะอนุญาตมัน เซิร์ฟเวอร์ที่ต้องการเปิดเผยสู่สาธารณะว่าทำไมคำขอจึงถูกห้ามสามารถอธิบายเหตุผลนั้นในส่วนของข้อมูลการตอบสนอง (ถ้ามี)

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

เซิร์ฟเวอร์ต้นทางที่ต้องการ "ซ่อน" การมีอยู่ของทรัพยากรเป้าหมายต้องห้ามในปัจจุบันอาจตอบกลับด้วยรหัสสถานะ 404 (ไม่พบ)

ในกรณีของ 401 vs 403 สิ่งนี้ได้รับการตอบหลายครั้ง นี่เป็นสิ่งสำคัญสำหรับการอภิปราย 'สภาพแวดล้อมคำขอ HTTP' ไม่ใช่การอภิปราย 'แอปพลิเคชัน'

ดูเหมือนจะมีคำถามเกี่ยวกับปัญหาการเข้าสู่ระบบของคุณ (แอปพลิเคชัน)

ในกรณีนี้การล็อกอินไม่เพียงพอที่จะส่ง 401 หรือ 403 เว้นแต่ว่าคุณใช้ HTTP Auth กับหน้าล็อกอิน (ไม่เชื่อมโยงกับการตั้งค่า HTTP Auth) ดูเหมือนว่าคุณอาจกำลังมองหา "201 สร้าง" โดยมีหน้าจอม้วนเข้าสู่ระบบของคุณปรากฏอยู่ (แทนที่จะเป็นทรัพยากรที่ร้องขอ) สำหรับการเข้าถึงไฟล์ในระดับแอปพลิเคชัน สิ่งนี้พูดว่า:

"ฉันได้ยินคุณมาที่นี่แล้วลองทำสิ่งนี้แทน (คุณไม่ได้รับอนุญาตให้ดู")