กำหนดเอง HTTP Authorization Header

124

ฉันสงสัยว่าสามารถใส่ข้อมูลที่กำหนดเองในส่วนหัวการอนุญาต HTTP ได้หรือไม่ เรากำลังออกแบบ RESTful API และเราอาจต้องการวิธีระบุวิธีการอนุญาตแบบกำหนดเอง ตัวอย่างเช่นเรียกว่าการFIRE-TOKENพิสูจน์ตัวตน

สิ่งนี้จะถูกต้องและได้รับอนุญาตตามข้อกำหนด: Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=

ส่วนแรกของสตริงที่สอง (ก่อน ':') คือคีย์ API ส่วนที่สองคือแฮชของสตริงข้อความค้นหา

— NRaf
แหล่งที่มา

133

รูปแบบที่กำหนดไว้ในRFC2617credentials = auth-scheme #auth-paramคือ ดังนั้นในการเห็นด้วยกับ fumanchu ฉันคิดว่ารูปแบบการอนุญาตที่ได้รับการแก้ไขจะเป็นอย่างไร

Authorization: FIRE-TOKEN apikey="0PN5J17HBGZHT7JJ3X82", hash="frJIUN8DYpKDtOLCwo//yllqDzg="

FIRE-TOKENโครงร่างอยู่ที่ไหนและคู่คีย์ - ค่าสองคู่คือพารามิเตอร์รับรองความถูกต้อง แม้ว่าฉันเชื่อว่าคำพูดนั้นเป็นทางเลือก (จาก Apendix B ของ p7-auth-19) ...

auth-param = token BWS "=" BWS ( token / quoted-string )

ฉันเชื่อว่าสิ่งนี้เหมาะกับมาตรฐานล่าสุดมีการใช้งานอยู่แล้ว (ดูด้านล่าง) และมีรูปแบบคีย์ - ค่าสำหรับส่วนขยายอย่างง่าย (หากคุณต้องการพารามิเตอร์เพิ่มเติม)

ตัวอย่างบางส่วนของไวยากรณ์ auth-param สามารถดูได้ที่นี่ ...

http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-4.4

https://developers.google.com/youtube/2.0/developers_guide_protocol_clientlogin

https://developers.google.com/accounts/docs/AuthSub#WorkingAuthSub

— StarTrekRedneck
แหล่งที่มา

4

API พื้นที่เก็บข้อมูลอย่างง่ายของ Amazonมีอีกตัวอย่างหนึ่ง

— อธิการ

18

ใส่ไว้ในส่วนหัวที่กำหนดเองแยกต่างหาก

การโหลดส่วนหัว HTTP มาตรฐานมากเกินไปอาจทำให้เกิดความสับสนมากกว่าที่ควรจะเป็นและจะละเมิดหลักการที่ทำให้ประหลาดใจน้อยที่สุด นอกจากนี้ยังอาจนำไปสู่ปัญหาความสามารถในการทำงานร่วมกันสำหรับโปรแกรมเมอร์ไคลเอ็นต์ API ของคุณที่ต้องการใช้ชุดเครื่องมือนอกชั้นวางที่สามารถจัดการกับรูปแบบมาตรฐานของส่วนหัว HTTP ทั่วไปเท่านั้น (เช่นAuthorization)

— Brian Kelly
แหล่งที่มา

3

สิ่งนี้อาจยากกว่าที่จะทำให้ถูกต้อง ลิงก์ที่ fumanchu ให้ไว้ (ในความคิดเห็นต่อคำตอบของเขา) อธิบายว่าเหตุใดการแนะนำส่วนหัวแบบกำหนดเองจึงเพิ่มภาระเพิ่มเติมในการตั้งค่า Cache-Control ด้วยตนเองให้ถูกต้อง

— Jon-Eric

4

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

— Wil Moore III

31

ส่วนหัวการตรวจสอบสิทธิ์ที่กำหนดเองไม่ได้มาก Authorizationส่วนหัวมาตรฐานข้อมูลจำเพาะที่มีรูปแบบที่คุณกำหนดเองควรจะเพียงพอ นอกจากนี้คุณยังหลีกเลี่ยงคำขอ Origin ก่อนเที่ยวบินตามที่ @wilmoore ระบุ โครงร่างที่กำหนดเองจะไม่รบกวนเซิร์ฟเวอร์ HTTP ที่ทันสมัยพอสมควรที่ฉันรู้จักนอกจากนี้หากคุณใช้โครงร่างของคุณเองคุณจะต้องแยกวิเคราะห์ด้วยตัวเอง - ไม่ควรขัดแย้งกับไลบรารี (มิฉะนั้นไลบรารีจะเขียนได้ไม่ดี)

— Les Hazlewood

7

เหตุผลที่ดีในการส่งข้อมูลรับรองในAuthorizationส่วนหัวแทนที่จะส่งในส่วนหัวที่กำหนดเองคือผู้รับมอบฉันทะและผู้ตัดไม้รู้ว่าข้อมูลนั้นมีความละเอียดอ่อน

— Eron Wright

15

ไม่มีที่ไม่ได้เป็นการผลิตที่ถูกต้องตามที่ "ข้อมูลประจำตัวของ" คำนิยามในRFC 2617 คุณให้รูปแบบการตรวจสอบสิทธิ์ที่ถูกต้อง แต่ค่า auth-param ต้องอยู่ในรูปแบบtoken "=" ( token | quoted-string )(ดูหัวข้อ 1.2) และตัวอย่างของคุณไม่ได้ใช้ "=" ในลักษณะนั้น

— fumanchu
แหล่งที่มา

1

ไม่ถูกต้อง ดูรูปแบบตัวอย่างในหน้า 5 ของเอกสาร: Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ ==

— NRaf

11

นั่นคือเรื่องจริง แต่ดังที่tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16#section-2.3.1กล่าวว่าสัญกรณ์ "b64token" ถูกนำมาใช้เพื่อให้เข้ากันได้กับรูปแบบการตรวจสอบสิทธิ์ที่มีอยู่และสามารถใช้ได้เพียงครั้งเดียวต่อ ความท้าทาย / ข้อมูลรับรองรูปแบบใหม่จึงควรใช้ไวยากรณ์ "auth-param" แทนเพราะไม่เช่นนั้นส่วนขยายในอนาคตจะเป็นไปไม่ได้ " ดูการอภิปรายเกี่ยวกับแคชที่นั่นเกี่ยวกับการตรวจสอบสิทธิ์ในส่วนหัวที่กำหนดเอง

— fumanchu

9

คำถามเก่าที่ฉันรู้ แต่สำหรับคนที่อยากรู้อยากเห็น:

เชื่อหรือไม่ว่าปัญหานี้ได้รับการแก้ไขเมื่อประมาณ 2 ทศวรรษที่แล้วด้วย HTTP BASIC ซึ่งส่งผ่านค่าเป็นชื่อผู้ใช้ที่เข้ารหัส base64: รหัสผ่าน (ดูhttp://en.wikipedia.org/wiki/Basic_access_authentication#Client_side )

คุณสามารถทำเช่นเดียวกันเพื่อให้ตัวอย่างด้านบนกลายเป็น:

Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==

— ไมค์ Marcacci
แหล่งที่มา

4

ฉันขอแนะนำให้ใช้คำตอบนี้ตามความคิดเห็นเกี่ยวกับคำตอบอื่นที่นี่สัญกรณ์ที่ใช้ในที่นี้มีไว้เพื่อความเข้ากันได้กับรูปแบบที่มีอยู่และไม่แนะนำสำหรับส่วนขยายใหม่

— Whymarrh