จุดเด่นของ Django: โมเดลผู้ใช้และการตรวจสอบสิทธิ์ (ตอนที่ 1)

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

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

ส่วนเพิ่มเติม ในซีรีส์:

• ไฮไลท์ของ Django: เทมเพลตบันทึกเส้น (ตอนที่ 2)
• จุดเด่นของ Django: โมเดล ผู้ดูแลระบบ และการควบคุมฐานข้อมูลเชิงสัมพันธ์ (ตอนที่ 3)
• ไฮไลท์ของ Django: การโต้เถียงเรื่องทรัพย์สินทางปัญญาและไฟล์สื่อ (ตอนที่ 4)

กำลังตั้งค่า

หากคุณต้องการสร้างแอปพลิเคชัน Django ของคุณเองเพื่อทดลองแนวคิดในบทความนี้ คุณสามารถสร้างไดเร็กทอรี (และควรเป็นสภาพแวดล้อมเสมือน) จากนั้นเรียกใช้คำสั่งต่อไปนี้:

 pip install django django-admin startproject PROJECTNAME cd PROJECTNAME python manage.py startapp APPNAME python manage.py migrate python manage.py runserver

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

รุ่นผู้ใช้มาตรฐาน

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

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

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

“

ในการสร้าง superuser บนแอปพลิเคชัน Django ของคุณเอง ให้เรียกใช้:

 python manage.py createsuperuser

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

ความปลอดภัยและความน่าเชื่อถือ

Django มีมิดเดิลแวร์การจัดการรหัสผ่านจำนวนมากพร้อมโมเดลผู้ใช้ รหัสผ่านของผู้ใช้ต้องมีอย่างน้อย 8 อักขระ ไม่ใช่ตัวเลขทั้งหมด ไม่ตรงกับชื่อผู้ใช้มากเกินไป และไม่อยู่ในรายการรหัสผ่านทั่วไป 20,000 รายการ แบบฟอร์มสต็อค Django ตรวจสอบข้อกำหนดเหล่านี้ เมื่อรหัสผ่านถูกส่งไปยังเซิร์ฟเวอร์ รหัสผ่านจะถูกเข้ารหัสก่อนที่จะจัดเก็บ โดยค่าเริ่มต้นโดยใช้อัลกอริทึม PBKDF2 ที่มีแฮช SHA256 โดยรวมแล้ว ระบบรหัสผ่านเริ่มต้นให้การรักษาความปลอดภัยที่แข็งแกร่งโดยไม่ต้องใช้ความพยายามใดๆ จากนักพัฒนา เว้นแต่คุณจะมีความเชี่ยวชาญเฉพาะด้านและเหตุผลที่น่าสนใจในการเปลี่ยนวิธีจัดการรหัสผ่านในแอปพลิเคชันของคุณ อย่าแก้ไขพฤติกรรมนี้

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

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

เว้นแต่คุณจะมีความเชี่ยวชาญเฉพาะด้านและเหตุผลที่น่าสนใจในการเปลี่ยนวิธีจัดการรหัสผ่านในแอปพลิเคชันของคุณ อย่าแก้ไขพฤติกรรมนี้

“

การใช้งานมาตรฐาน

เมื่อคุณต้องการลงทะเบียนบัญชีผู้ใช้ใหม่ มุมมองสำหรับการทำเช่นนั้นอาจมีลักษณะดังนี้ใน views.py :

 from django.shortcuts import render, redirect from django.contrib.auth import authenticate, login from django.contrib.auth.forms import UserCreationForm def signup(request): if request.user.is_authenticated: return redirect('/') if request.method == 'POST': form = UserCreationForm(request.POST) if form.is_valid(): form.save() username = form.cleaned_data.get('username') password = form.cleaned_data.get('password1') user = authenticate(username=username, password=password) login(request, user) return redirect('/') else: return render(request, 'signup.html', {'form': form}) else: form = UserCreationForm() return render(request, 'signup.html', {'form': form})

มาทำลายมันกันเถอะ:

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

กำลังตรวจสอบการลงชื่อเข้าใช้บัญชี:

 from django.shortcuts import render, redirect from django.contrib.auth import authenticate, login from django.contrib.auth.forms import AuthenticationForm def signin(request): if request.user.is_authenticated: return render(request, 'homepage.html') if request.method == 'POST': username = request.POST['username'] password = request.POST['password'] user = authenticate(request, username=username, password=password) if user is not None: login(request, user) return redirect('/') else: form = AuthenticationForm(request.POST) return render(request, 'signin.html', {'form': form}) else: form = AuthenticationForm() return render(request, 'signin.html', {'form': form})

รายละเอียดอื่น:

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

สุดท้ายนี้ ผู้ใช้ของคุณอาจต้องการออกจากระบบ รหัสพื้นฐานสำหรับคำขอนี้ง่ายมาก:

 from django.shortcuts import render, redirect from django.contrib.auth import logout def signout(request): logout(request) return redirect('/')

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

ในขณะที่ผู้ใช้มีเซสชันที่ใช้งานอยู่ในอุปกรณ์ พวกเขาจะลงทะเบียนเป็น True สำหรับการตรวจสอบ request.user.is_authenticated อีกวิธีหนึ่งในการจำกัดหน้าสำหรับผู้ใช้ที่เข้าสู่ระบบเท่านั้นคือ @login_required decorator เหนือฟังก์ชัน มีอีกหลายวิธีในการบรรลุสิ่งเดียวกัน โปรดดูรายละเอียดที่นี่

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

การขยายรูปแบบผู้ใช้

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

การลดฟิลด์จากโมเดลผู้ใช้

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

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

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

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

“

การเพิ่มฟิลด์ด้วยโปรไฟล์

ในทำนองเดียวกัน หากคุณต้องการเก็บข้อมูลเพิ่มเติมเกี่ยวกับผู้ใช้ของคุณ คุณไม่ควรพยายามแก้ไขรูปแบบผู้ใช้เริ่มต้น แม้แต่ฟิลด์เดียว ให้กำหนดออบเจ็กต์ของคุณเองด้วยความสัมพันธ์แบบหนึ่งต่อหนึ่งกับผู้ใช้ที่มีอยู่ โมเดลพิเศษนี้มักเรียกว่า Profile สมมติว่าคุณต้องการเก็บชื่อกลางและวันเกิด (dob) สำหรับผู้ใช้แต่ละคน Profile จะถูกกำหนดดังต่อไปนี้ใน models.py :

 from django.db import models from django.contrib.auth.models import User class Profile(models.Model): user = models.OneToOneField(User, on_delete=models.CASCADE) middle_name = models.CharField(max_length=30, blank=True) dob = models.DateField(null=True, blank=True)

การควบคุมการเข้าถึงแบบกำหนดเอง

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

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

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

ภาพรวม: การผสานรวมผู้ให้บริการการชำระเงิน

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

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

ภาพรวม: การลงชื่อเข้าใช้โซเชียล

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

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

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

หากคุณตัดสินใจว่าการรับรองความถูกต้องทางสังคมเหมาะสำหรับแอปพลิเคชันของคุณ โชคดีที่มีห้องสมุดสำหรับสิ่งนั้น Python Social Auth สำหรับ Django เป็นแพ็คเกจสำหรับเปิดใช้งานความสามารถของระบบนิเวศการตรวจสอบสิทธิ์ทางสังคมของ Python ในโครงการ Django

ห่อ

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

Django Highlights เป็นซีรีส์ที่นำเสนอแนวคิดที่สำคัญของการพัฒนาเว็บใน Django แต่ละบทความเขียนขึ้นเพื่อเป็นแนวทางแบบสแตนด์อโลนในด้านการพัฒนา Django เพื่อช่วยให้นักพัฒนาส่วนหน้าและนักออกแบบเข้าถึงความเข้าใจที่ลึกซึ้งยิ่งขึ้นของ "อีกครึ่งหนึ่ง" ของโค้ดเบส บทความเหล่านี้ส่วนใหญ่สร้างขึ้นเพื่อช่วยให้คุณเข้าใจทฤษฎีและแบบแผน แต่มีตัวอย่างโค้ดบางส่วนซึ่งเขียนใน Django 3.0 แนวคิดต่างๆ ที่เราได้กล่าวถึงในบทความนี้ รวมถึงเทมเพลต ผู้ใช้ที่เป็นผู้ดูแลระบบ โมเดล และแบบฟอร์ม จะได้รับการสำรวจโดยละเอียดเป็นรายบุคคลในบทความต่อๆ ไปในชุดนี้

ส่วนเพิ่มเติม ในซีรีส์:

• ไฮไลท์ของ Django: เทมเพลตบันทึกเส้น (ตอนที่ 2)
• จุดเด่นของ Django: โมเดล ผู้ดูแลระบบ และการควบคุมฐานข้อมูลเชิงสัมพันธ์ (ตอนที่ 3)
• ไฮไลท์ของ Django: การโต้เถียงเรื่องทรัพย์สินทางปัญญาและไฟล์สื่อ (ตอนที่ 4)