เราทุกคนเคยไปที่นั่น คุณกำลังทำงานในส่วนแบ็คเอนด์ของ API และคุณพอใจกับการดำเนินการ คุณเพิ่งทำผลิตภัณฑ์ขั้นต่ำ (MVP) เสร็จสิ้นการทดสอบทั้งหมดผ่านแล้วและคุณรอคอยที่จะนำคุณลักษณะใหม่ ๆ มาใช้

จากนั้นเจ้านายจะส่งอีเมลถึงคุณ:“ ยังไงก็ตามเราต้องให้คนล็อกอินผ่าน Facebook และ Google พวกเขาไม่ควรต้องสร้างบัญชีสำหรับไซต์เล็ก ๆ เช่นเดียวกับเรา”

เยี่ยมมาก ขอบเขตคืบคลานอีกครั้ง

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

เป็นไปได้ว่าคุณไม่คุ้นเคยกับ OAuth 2 ฉันไม่ได้เมื่อสิ่งนี้เกิดขึ้นกับฉัน

ในฐานะที่เป็น นักพัฒนา Python สัญชาตญาณของคุณอาจนำไปสู่คุณ pip เครื่องมือแนะนำ Python Package Index (PyPA) สำหรับการติดตั้งแพ็คเกจ Python ข่าวร้ายคือ pip รู้เกี่ยวกับ 278 แพ็คเกจที่จัดการกับ OAuth - 53 รายการที่กล่าวถึงโดยเฉพาะ Django . เป็นเวลาหนึ่งสัปดาห์ที่คุ้มค่ากับการทำงานเพื่อค้นคว้าตัวเลือกต่างๆ แต่อย่าลืมเริ่มเขียนโค้ด

ในบทช่วยสอนนี้คุณจะได้เรียนรู้วิธีรวม OAuth 2 เข้ากับ Django หรือ Django Rest Framework โดยใช้ Python Social Auth . แม้ว่าบทความนี้จะมุ่งเน้นไปที่ Django REST Framework แต่คุณสามารถใช้ข้อมูลที่ให้ไว้ที่นี่เพื่อใช้งานแบบเดียวกันใน back-end framework ทั่วไปอื่น ๆ

ภาพรวมโดยย่อของโฟลว์ OAuth 2

OAuth 2 ได้รับการออกแบบมาตั้งแต่แรกเป็นโปรโตคอลการตรวจสอบสิทธิ์เว็บ สิ่งนี้ไม่เหมือนกับว่ามันได้รับการออกแบบมาเป็นโปรโตคอลการตรวจสอบสิทธิ์สุทธิ สมมติว่าคุณมีเครื่องมือเช่นการแสดงผล HTML และการเปลี่ยนเส้นทางเบราว์เซอร์

เห็นได้ชัดว่านี่เป็นอุปสรรคสำหรับ API ที่ใช้ JSON แต่คุณสามารถแก้ไขได้

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

โฟลว์ OAuth 2 ฝั่งเซิร์ฟเวอร์

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

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

โทเค็นอ้างถึงรหัสเซิร์ฟเวอร์ของคุณเป็นไคลเอนต์ โฮสต์คือผู้ให้บริการ OAuth 2 ไม่ได้มีไว้สำหรับลูกค้า API ของคุณ

สถานที่ที่ดีที่สุดในการเรียนรู้ c

ขั้นตอนนี้เริ่มต้นเมื่อแอปพลิเคชันของคุณสร้างเพจที่มีปุ่มเช่น“ เข้าสู่ระบบด้วย Facebook” หรือ“ ลงชื่อเข้าใช้ด้วย Google+” โดยพื้นฐานแล้วสิ่งเหล่านี้ไม่ใช่สิ่งอื่นใดนอกจากลิงก์ธรรมดาซึ่งแต่ละลิงก์จะชี้ไปที่ URL ดังต่อไปนี้:

https://oauth2provider.com/auth? response_type=code& client_id=CLIENT_KEY& redirect_uri=CALLBACK_URI& scope=profile& scope=email

(หมายเหตุ: ตัวแบ่งบรรทัดแทรกลงใน URI ด้านบนเพื่อให้อ่านง่าย)

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

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

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

สมมติว่าผู้ใช้อนุมัติเซิร์ฟเวอร์ OAuth 2 จะเปลี่ยนเส้นทางกลับไปยัง URI การเรียกกลับที่คุณระบุรวมถึง รหัสการอนุญาต ในพารามิเตอร์การค้นหา: GET https://api.yourapp.com/oauth2/callback/?code=AUTH_CODE.

รหัสการให้สิทธิ์เป็นโทเค็นแบบใช้ครั้งเดียวที่หมดอายุอย่างรวดเร็ว ทันทีที่ได้รับเซิร์ฟเวอร์ของคุณควรกลับมาและส่งคำขออีกครั้งไปยังผู้ให้บริการ OAuth 2 รวมทั้งรหัสการให้สิทธิ์และข้อมูลลับของไคลเอ็นต์ของคุณ:

POST https://oauth2provider.com/token/? grant_type=authorization_code& code=AUTH_CODE& redirect_uri=CALLBACK_URI& client_id=CLIENT_KEY& client_secret=CLIENT_SECRET

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

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

การโทรนี้ส่งตรงจากเซิร์ฟเวอร์ของคุณไปยังเซิร์ฟเวอร์ของผู้ให้บริการ OAuth 2 เป็นองค์ประกอบหลักของกระบวนการเข้าสู่ระบบฝั่งเซิร์ฟเวอร์ OAuth 2 การควบคุมการโทรหมายความว่าคุณรู้ว่าการโทรนั้นปลอดภัยด้วย TLS ดังนั้นจึงช่วยป้องกันการโจมตีด้วยการดักฟังโทรศัพท์

ตัวอย่างใบหุ้นทุน

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

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

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

ไม่ควรให้โทเค็นการเข้าถึงแก่ผู้ใช้!

มีรายละเอียดเพิ่มเติมที่เราสามารถเจาะลึกได้

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

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

โชคดีที่มีขั้นตอน OAuth 2 อีกแบบซึ่งใช้ได้ดีกว่ามากในกรณีนี้

ขั้นตอน OAuth 2 ฝั่งไคลเอ็นต์

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

ขั้นตอนแรกเช่นเดียวกับในโฟลว์ฝั่งเซิร์ฟเวอร์คือการลงทะเบียนแอปพลิเคชัน

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

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

URL ดูแตกต่างกันเล็กน้อยในครั้งนี้:

https://oauth2provider.com/auth? response_type=token& client_id=CLIENT_KEY& redirect_uri=CALLBACK_URI& scope=profile& scope=email

โปรดทราบว่า response_type พารามิเตอร์ในครั้งนี้ใน URL คือ token

แล้ว URI เปลี่ยนเส้นทางล่ะ

นี่เป็นเพียงที่อยู่ใด ๆ บนส่วนหน้าที่เตรียมไว้สำหรับจัดการโทเค็นการเข้าถึงอย่างเหมาะสม

อุตสาหกรรมเครื่องสำอางใหญ่แค่ไหน

ทั้งนี้ขึ้นอยู่กับไลบรารี OAuth 2 ที่ใช้งานส่วนหน้าอาจเรียกใช้เซิร์ฟเวอร์ชั่วคราวที่สามารถรับคำขอ HTTP บนอุปกรณ์ของผู้ใช้ได้โดยขึ้นอยู่กับไลบรารี OAuth 2 ในกรณีนั้น URL การเปลี่ยนเส้นทางจะอยู่ในรูปแบบ http://localhost:7862/callback/?token=TOKEN

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

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

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

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

โฟลว์ฝั่งไคลเอ็นต์ช่วยให้มีการแยกที่เข้มงวดขึ้นระหว่าง back-end REST API และ front-end ที่ผู้ใช้หันหน้าเข้าหาผู้ใช้ ไม่มีอะไรหยุดคุณอย่างเคร่งครัดในการระบุเซิร์ฟเวอร์ส่วนหลังของคุณเป็น URI การเปลี่ยนเส้นทาง ผลสุดท้ายน่าจะเป็นการไหลแบบผสมผสาน

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

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

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

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

นี่คือสูตรสำหรับการแลกเปลี่ยนโทเค็นที่แบ็คเอนด์

ภายใต้ขั้นตอนไคลเอนต์แบ็คเอนด์ค่อนข้างแยกออกจากกระบวนการ OAuth 2 อย่าหลงผิด: นี่ไม่ใช่งานง่ายๆ คุณจะต้องสนับสนุนฟังก์ชันอย่างน้อยดังต่อไปนี้

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

ข่าวดีก็คือการใช้ฟังก์ชันทั้งหมดนี้ในแบ็คเอนด์นั้นง่ายกว่าที่คุณคาดไว้มาก

นี่คือความมหัศจรรย์สำหรับวิธีทำให้ทั้งหมดนี้ทำงานบนแบ็คเอนด์ด้วยโค้ดสองโหล ขึ้นอยู่กับไฟล์ Python Social Auth ห้องสมุด (“ PSA” ต่อจากนี้ไป) ดังนั้นคุณจะต้องรวมทั้ง social-auth-core และ social-auth-app-django ใน requirements.txt ของคุณ

คุณจะต้องกำหนดค่าไลบรารีตามเอกสารด้วย ที่นี่ . โปรดทราบว่าสิ่งนี้ไม่รวมการจัดการข้อยกเว้นบางอย่างเพื่อความชัดเจน

สามารถพบโค้ดเต็มสำหรับตัวอย่างนี้ ที่นี่ .

@api_view(http_method_names=['POST']) @permission_classes([AllowAny]) @psa() def exchange_token(request, backend): serializer = SocialSerializer(data=request.data) if serializer.is_valid(raise_exception=True): # This is the key line of code: with the @psa() decorator above, # it engages the PSA machinery to perform whatever social authentication # steps are configured in your SOCIAL_AUTH_PIPELINE. At the end, it either # hands you a populated User model of whatever type you've configured in # your project, or None. user = request.backend.do_auth(serializer.validated_data['access_token']) if user: # if using some other token back-end than DRF's built-in TokenAuthentication, # you'll need to customize this to get an appropriate token object token, _ = Token.objects.get_or_create(user=user) return Response({'token': token.key}) else: return Response( {'errors': {'token': 'Invalid token'}}, status=status.HTTP_400_BAD_REQUEST, )

มีอีกเล็กน้อยที่ต้องดำเนินการในการตั้งค่าของคุณ ( รหัสเต็ม ) จากนั้นคุณก็พร้อม:

AUTHENTICATION_BACKENDS = ( 'social_core.backends.google.GoogleOAuth2', 'social_core.backends.facebook.FacebookOAuth2', 'django.contrib.auth.backends.ModelBackend', ) for key in ['GOOGLE_OAUTH2_KEY', 'GOOGLE_OAUTH2_SECRET', 'FACEBOOK_KEY', 'FACEBOOK_SECRET']: # Use exec instead of eval here because we're not just trying to evaluate a dynamic value here; # we're setting a module attribute whose name varies. exec('SOCIAL_AUTH_{key} = os.environ.get('{key}')'.format(key=key)) SOCIAL_AUTH_PIPELINE = ( 'social_core.pipeline.social_auth.social_details', 'social_core.pipeline.social_auth.social_uid', 'social_core.pipeline.social_auth.auth_allowed', 'social_core.pipeline.social_auth.social_user', 'social_core.pipeline.user.get_username', 'social_core.pipeline.social_auth.associate_by_email', 'social_core.pipeline.user.create_user', 'social_core.pipeline.social_auth.associate_user', 'social_core.pipeline.social_auth.load_extra_data', 'social_core.pipeline.user.user_details', )

เพิ่มการแมปลงในฟังก์ชันนี้ใน urls.py ของคุณเท่านี้คุณก็พร้อมแล้ว!

เวทมนตร์นั้นทำงานอย่างไร?

Python Social Auth เป็นเครื่องจักรที่ยอดเยี่ยมและซับซ้อนมาก เรายินดีอย่างยิ่งที่จะจัดการการตรวจสอบสิทธิ์และการเข้าถึงข้อมูลใด ๆ ผู้ให้บริการตรวจสอบสิทธิ์ทางสังคมหลายโหล และใช้งานได้กับเว็บเฟรมเวิร์ก Python ยอดนิยมรวมถึง Django , กระติกน้ำ , พีระมิด , CherryPy และ WebPy .

โค้ชเปรียวคืออะไร

ส่วนใหญ่โค้ดด้านบนเป็นมุมมองที่ใช้ฟังก์ชันตามมาตรฐาน Django REST framework (DRF) ซึ่งจะรับฟังคำขอ POST บนเส้นทางใดก็ตามที่คุณแมปไว้ใน urls.py และสมมติว่าคุณส่งคำขอในรูปแบบที่ต้องการมันจะทำให้คุณได้รับ User วัตถุหรือ None.

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

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

ความมหัศจรรย์ที่สำคัญคือ @psa() มัณฑนากรในมุมมองซึ่งเพิ่มสมาชิกบางส่วนใน request วัตถุที่ส่งผ่านไปยังมุมมองของคุณ สิ่งที่น่าสนใจที่สุดสำหรับเราคือ request.backend (สำหรับ PSA แบ็กเอนด์คือผู้ให้บริการตรวจสอบสิทธิ์ทางสังคม)

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

เมื่อคุณมี backend มีวัตถุอยู่ในมือเรายินดีอย่างยิ่งที่จะรับรองความถูกต้องของคุณกับผู้ให้บริการรายนั้นโดยให้รหัสการเข้าถึงของคุณ นั่นคือ do_auth วิธี. ในทางกลับกันสิ่งนี้จะมีส่วนร่วมทั้งหมดของ SOCIAL_AUTH_PIPELINE จากไฟล์กำหนดค่าของคุณ

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

หลังจากนั้นจะกลับมาเป็นรหัส DRF ปกติ: หากคุณมี User ที่ถูกต้อง คุณสามารถส่งคืนโทเค็น API ที่เหมาะสมได้อย่างง่ายดาย หากคุณไม่ได้รับ User ที่ถูกต้อง คัดค้านมันง่ายที่จะสร้างข้อผิดพลาด

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

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

ทำไมไม่ม้วนของคุณเอง?

ในคำ: ความสามารถในการขยาย ผู้ให้บริการ OAuth 2 ทางโซเชียลมีเพียงไม่กี่รายที่ต้องการหรือส่งคืนข้อมูลเดียวกันในการเรียก API ด้วยวิธีเดียวกันทั้งหมด มีกรณีพิเศษและข้อยกเว้นทุกประเภท

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

ฉันจะทดสอบสิ่งนี้บนโลกได้อย่างไร

คำถามที่ดี! unittest.mock ไม่เหมาะอย่างยิ่งที่จะล้อเลียนการเรียก API ที่ฝังอยู่ภายใต้ชั้นนามธรรมที่อยู่ลึกเข้าไปในไลบรารี เพียงแค่ค้นพบเส้นทางที่แม่นยำในการล้อเลียนก็ต้องใช้ความพยายามอย่างมาก

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

การอภิปรายทั้งหมดเกี่ยวกับการทดสอบอยู่นอกเหนือขอบเขตของบทความนี้ แต่มีตัวอย่างการทดสอบของเรา ที่นี่ . ฟังก์ชั่นเฉพาะที่ควรทราบ ได้แก่ mocked ตัวจัดการบริบทและ SocialAuthTests ชั้นเรียน

ให้ PSA ทำการยกของหนัก

กระบวนการ OAuth2 มีรายละเอียดและซับซ้อนโดยมีความซับซ้อนโดยธรรมชาติมากมาย โชคดีที่เป็นไปได้ที่จะหลีกเลี่ยงความซับซ้อนดังกล่าวโดยนำห้องสมุดที่ทุ่มเทเพื่อจัดการกับมันอย่างไม่ลำบากเท่าที่จะทำได้

Python Social Auth ทำได้ดีมาก เราได้แสดงให้เห็นมุมมอง Django / DRF ที่ใช้โฟลว์ OAuth2 ฝั่งไคลเอ็นต์เพื่อสร้างผู้ใช้ที่ราบรื่นและจับคู่ในโค้ดเพียง 25 บรรทัด ไม่โทรมเกินไป