HTTP 407 หรือ 401: การเข้าสู่ระบบฝั่งไหนล้มเหลว
แยกการยืนยันตัวตนกับพร็อกซีออกจากเว็บไซต์ ตรวจสอบเฮดเดอร์ที่ถูกต้อง และไม่ส่งข้อมูลเข้าสู่ระบบให้ผิดฝั่ง
407 ขอให้ยืนยันตัวตนกับพร็อกซี ส่วน 401 ขอให้ยืนยันตัวตนสำหรับทรัพยากรปลายทาง คำขอเดียวอาจเจอทั้งสองอย่าง จึงควรรู้ก่อนว่าใครเป็นผู้ขอแล้วค่อยให้รหัสผ่าน
เทียบสถานะกับเฮดเดอร์ที่ร้องขอการยืนยันตัวตน
| คำตอบ | เฮดเดอร์คำร้องขอการยืนยันตัวตน | เฮดเดอร์ข้อมูลเข้าสู่ระบบ | ฝ่ายที่เกี่ยวข้อง |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | พร็อกซีตัวกลาง |
| 401 Unauthorized | WWW-Authenticate | Authorization | กระบวนการยืนยันตัวตนของทรัพยากรต้นทาง |
สถานะเป็นเบาะแสแรกที่สำคัญ แต่ต้องดูการแลกเปลี่ยนทั้งหมด หน้าเว็บที่เขียนเลข 407 ในเนื้อหาไม่เท่ากับคำตอบ HTTP 407 จริง เช่นเดียวกับหน้าเข้าสู่ระบบเฉพาะของเว็บที่อาจคืน 200 แต่ยังขอให้ยืนยันตัวตนในชั้นแอปพลิเคชัน
ทำไม HTTPS จึงเจอ 407 ก่อนถึงเว็บไซต์ได้
เมื่อพร็อกซี HTTP ทั่วไปส่งต่อคำขอ HTTPS ไคลเอนต์มักขอให้สร้างอุโมงค์ CONNECTก่อน พร็อกซีอาจขอให้ยืนยันตัวตนสำหรับคำขอ CONNECT นั้น หากยังไม่สำเร็จ เซสชัน TLS กับปลายทางผ่านอุโมงค์ก็ยังไม่ถูกสร้าง การเปลี่ยน API token ของเว็บไซต์จึงไม่น่าจะแก้ขั้นตอนนี้ได้
ใช้เอาต์พุตแบบละเอียดเพื่อดูว่าคำร้องขอปรากฏตรงไหน:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/เปลี่ยนลิสเทนเนอร์ในเครื่องเป็นของคุณแล้วอ่านคำร้องขอแรกในบันทึก 407 ระหว่าง CONNECT เกิดก่อน TLS ของปลายทาง ส่วน 401 ภายหลังอาจเกิดหลังสร้างอุโมงค์สำเร็จแล้ว
ส่งข้อมูลพร็อกซีผ่านอินเทอร์เฟซสำหรับพร็อกซี
สำหรับเอนด์พอยต์และบัญชีที่ผู้ดูแลที่คุณไว้ใจจัดให้ curl สามารถเจรจาวิธียืนยันตัวตนของพร็อกซีและถามรหัสผ่านที่ไม่ได้ระบุได้:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/แทนเอนด์พอยต์และชื่อผู้ใช้ตัวอย่างด้วยข้อมูลบริการที่คุณได้รับอนุญาตให้ใช้ การระบุเฉพาะผู้ใช้ช่วยไม่ให้รหัสผ่านอยู่ตรง ๆ ในคำสั่งข้างบน วิธีที่รองรับอาจต่างกันตามบิลด์ curl และพร็อกซี หากเจรจาไม่สำเร็จให้ดูคำร้องขอจริงและความสามารถของบิลด์
ตัวเลือกยืนยันตัวตนกับพร็อกซีแยกจากตัวเลือกผู้ใช้ของเซิร์ฟเวอร์ต้นทางใน curl อย่าเพิ่ม Authorization ของต้นทางแทนคำตอบต่อคำร้องขอของพร็อกซี และอย่าส่งต่อเฮดเดอร์ข้อมูลพร็อกซีไปยังคำขอที่ไม่เกี่ยวข้องเอง หรือเก็บไว้ในเฮดเดอร์ที่ใช้ร่วมกันทั้งแอป
ถ้าพร็อกซียังส่ง 407 กลับมา
- ยืนยันว่าใช้โฮสต์และพอร์ตพร็อกซีที่ตั้งใจไว้
- ตรวจสอบวิธีที่พร็อกซีประกาศ แทนการสมมติว่าเป็น Basic
- ยืนยันสถานะบัญชีและรูปแบบชื่อผู้ใช้ที่บริการอาจกำหนด
- ตรวจสอบวิธีส่งอักขระพิเศษหากข้อมูลอยู่ใน URL
- ดูว่าการยืนยันตัวตนองค์กรที่รวมกับเบราว์เซอร์ต้องการการรองรับจากรันไทม์หรือแพลตฟอร์มหรือไม่
- หากหลักฐานฝั่งไคลเอนต์ไม่พอ ขอรหัสคำขอหรือบันทึกฝั่งเซิร์ฟเวอร์ที่ลบข้อมูลอ่อนไหวแล้วจากผู้ดูแล
403 หรือ CONNECT ที่ถูกปฏิเสธอาจเป็นการตัดสินใจตามนโยบายเข้าถึง แม้เข้าสู่ระบบสำเร็จแล้ว การลองรหัสผ่านเพิ่มไม่ทำให้เข้าถึงปลายทางต้องห้ามได้
HTTPS ของปลายทางไม่ได้ปกป้องการส่งข้อมูลพร็อกซีทุกครั้ง
การยืนยันตัวตนกับพร็อกซีอาจเกิดก่อน TLS ของปลายทาง หากการเชื่อมต่อกับพร็อกซีเองไม่เข้ารหัส และวิธีนั้นเปิดเผยข้อมูลที่นำกลับมาใช้ได้บนเส้นทางนี้ ปลายทาง HTTPS ก็ไม่ปกป้องการแลกเปลี่ยนนั้นย้อนหลัง เลือกการส่งข้อมูลและการยืนยันตัวตนที่เหมาะกับบริการ และอย่าส่งบัญชีส่วนตัวให้พร็อกซีสาธารณะที่ไม่รู้จัก
ตรวจสอบบันทึกแบบละเอียดก่อนแชร์ แม้เครื่องมือจะปิดบังช่องข้อมูลเข้าสู่ระบบทั่วไป ก็อาจยังมีชื่อผู้ใช้ ชื่อเอนด์พอยต์ภายใน คุกกี้ หรือข้อมูลระบุตัวตนอื่นอยู่