يسلط الضوء على Django: نماذج المستخدم والمصادقة (الجزء الأول)

هناك نوعان من مواقع الويب: ثابت وديناميكي. Django هو إطار عمل لتطوير المواقع الديناميكية. في حين أن موقع الويب الثابت هو الذي يقدم المعلومات فقط ، فلا يوجد تفاعل (يتجاوز طلبات الصفحة البسيطة) يتم تسجيله في الخادم. في موقع ويب ثابت ، يرسل الخادم HTML و CSS و JavaScript إلى العميل وهذا كل شيء. تتطلب المزيد من الإمكانات موقع ويب ديناميكيًا ، حيث يخزن الخادم المعلومات ويستجيب لتفاعل المستخدم بما يتجاوز مجرد عرض الصفحات. أحد الأسباب الرئيسية لتطوير موقع ديناميكي هو مصادقة المستخدمين وتقييد المحتوى.

إن كتابة موقع ويب ثابت ونشره وإدارته هو أمر أسهل وأرخص وأكثر أمانًا من موقع ديناميكي. وبالتالي ، يجب عليك فقط إنشاء موقع ويب ديناميكي إذا كانت القدرات الإضافية للنموذج الديناميكي ضرورية لمشروعك. يبسط Django ويبسط عملية إنشاء موقع ديناميكي بمكوناته المدمجة. كأحد المكونات الأساسية لتطبيق ويب ديناميكي ، فإن كائن "حساب المستخدم" ، مثل العجلة ، يغري بإعادة الاختراع ، لكن الشكل القياسي مناسب لمعظم الاستخدامات. يوفر Django نموذج مستخدم قويًا جاهزًا ، وفي هذه المقالة ، سنتعرف على أفضل طريقة لتوفير تدفقات مصادقة آمنة وبديهية للمستخدم.

أجزاء أخرى في السلسلة:

• يسلط الضوء على Django: تصميم خطوط حفظ النماذج (الجزء الثاني)
• يسلط الضوء على Django: النماذج والمسؤول وتسخير قاعدة البيانات العلائقية (الجزء 3)
• أهم أحداث Django: الأصول الثابتة وملفات الوسائط (الجزء الرابع)

التجهيز

إذا كنت ترغب في إنشاء تطبيق 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: حسابات المستخدمين المتميزين والمستخدمين العاديين. يتمتع المستخدمون المتميزون بكل سمات وامتيازات الحسابات العادية ، ولكن يمكنهم أيضًا الوصول إلى لوحة إدارة Django ، وهو تطبيق قوي سنستكشفه بالتفصيل في مقال مستقبلي. بشكل أساسي ، يمكن للمستخدمين المتميزين إنشاء أو تحرير أو حذف أي بيانات في التطبيق ، بما في ذلك حسابات المستخدمين الأخرى.

في الأساس ، يوجد مفهوم حساب المستخدم لسببين: التحكم في الوصول وحالة التطبيق الشخصية.

"

لإنشاء مستخدم متميز على تطبيق Django الخاص بك ، قم بتشغيل:

 python manage.py createsuperuser

الميزة الأخرى لحساب المستخدم هي تخزين البيانات الشخصية في قاعدة البيانات. افتراضيًا ، لا يطلب Django سوى اسم مستخدم وكلمة مرور ولكنه يوفر حقولًا اختيارية للمستخدمين لإدخال الاسم الأول واسم العائلة وعنوان البريد الإلكتروني. يمكنك قراءة مرجع نموذج كامل على موقع Django. سنناقش تمديد هذا النموذج أدناه.

الأمان والموثوقية

يتضمن Django برمجيات وسيطة لإدارة كلمات المرور مع نموذج المستخدم. يجب ألا تقل كلمات مرور المستخدم عن 8 أحرف ، وليست أرقامًا كاملة ، وألا تتطابق بشكل كبير مع اسم المستخدم ، وألا تكون مدرجة في قائمة تضم 20000 كلمة مرور شائعة. تتحقق نماذج مخزون Django من صحة هذه المتطلبات. عند إرسال كلمة مرور إلى الخادم ، يتم تشفيرها قبل تخزينها ، افتراضيًا باستخدام خوارزمية PBKDF2 مع تجزئة SHA256. بشكل عام ، يوفر نظام كلمة المرور الافتراضي أمانًا قويًا دون أي جهد من المطور. ما لم تكن لديك خبرة محددة وسببًا مقنعًا لتغيير طريقة التعامل مع كلمات المرور في تطبيقك ، فلا تقم بتعديل هذا السلوك.

أحد الأشياء المضمنة المريحة الأخرى هو اشتراط أن تكون أسماء المستخدمين فريدة. إذا فكرت في الأمر ، إذا كان هناك مستخدمان باسم المستخدم "djangofan1" وتلقى الخادم طلب تسجيل دخول لاسم المستخدم هذا ، فلن يعرف المستخدم الذي كان يحاول الوصول إلى التطبيق. لسوء حظهم ، سيتعين على المستخدم الثاني الذي يحاول التسجيل في "djangofan1" اختيار اسم مختلف ، ربما "djangofan2". يتم فرض هذا القيد الفريد على مستوى قاعدة البيانات ولكن يتم التحقق منه مرة أخرى بواسطة النماذج التي يوفرها Django.

أخيرًا ، ملاحظة حول حذف المستخدمين. بينما يعد حذف المستخدمين أمرًا محتملاً ، سيكون لمعظم التطبيقات المعقدة عدد من الموارد المرتبطة بكل حساب مستخدم. إذا كنت تريد حذف مستخدم بشكل فعال دون إزالة تلك الكائنات المرفقة ، فاضبط حقل is_active للمستخدم على خطأ بدلاً من ذلك. بعد ذلك ، تظل هذه الموارد الأخرى مرتبطة بالحساب بدلاً من حذفها بنفسها ، ويمكن إعادة تنشيط حساب المستخدم في أي وقت بواسطة مستخدم متميز. لاحظ أن هذا لا يؤدي إلى تحرير اسم المستخدم ، ولكن تعيين الحساب على أنه غير نشط بالتزامن مع تغيير اسم المستخدم إلى قيمة عشوائية وفريدة يمكن أن يحقق نفس التأثير. أخيرًا ، إذا كانت سياسات موقعك أو القانون المحلي المعمول به يتطلب حذف حسابات المستخدمين بالكامل ، فلن يكون نهج 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 check. هناك طريقة أخرى لتقييد الصفحات للمستخدمين الذين قاموا بتسجيل الدخول فقط وهي مصمم @login_required أعلى الوظيفة. هناك عدة طرق أخرى لتحقيق ذلك ، مفصلة هنا.

إذا كان هذا المستوى من التكوين أكثر مما تريد القيام به ، فهناك نهج أكثر تقليدية لإدارة المستخدم. توفر طرق عرض مصادقة المخزون هذه مسارات وطرق عرض ونماذج قياسية لإدارة المستخدم ويمكن تعديلها عن طريق تعيينها لعناوين 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 لتنفيذ هذا النمط هي المجموعة. يمكن أن تحتوي المجموعة على أي عدد من الأذونات ، والتي يمكن تعيين كل منها لأي عدد من المجموعات. ثم يحصل المستخدم على أذونات ليس بشكل مباشر ولكن من خلال عضويته في المجموعات ، مما يسهل إدارة التطبيق.

نظرة عامة: دمج مزود الدفع

تختلف العملية الدقيقة لدمج معالج الدفع بشكل كبير حسب التطبيق والمزود. ومع ذلك ، سأغطي العملية بعبارات عامة.

تتمثل إحدى المزايا الرئيسية لمدفوعات الاستعانة بمصادر خارجية في أن المزود مسؤول عن تخزين والتحقق من صحة البيانات شديدة التنظيم مثل معلومات بطاقة الائتمان. تشارك الخدمة بعد ذلك بعض رموز المستخدم الفريدة مع تطبيقك إلى جانب بيانات حول سجل الدفع الخاص بهم. مثل إضافة ملف التعريف ، يمكنك إنشاء نموذج مرتبط User الأساسي وتخزين البيانات في هذا النموذج. كما هو الحال مع كلمات المرور ، من المهم اتباع التكامل المحدد مع الموفر لتجنب تخزين المعلومات الحساسة بشكل غير صحيح.

نظرة عامة: تسجيل الدخول عبر شبكات التواصل الاجتماعي

المجال الآخر الواسع والمعقد الذي أريد أن أتطرق إليه بإيجاز هو تسجيل الدخول الاجتماعي. توفر الأنظمة الأساسية الكبيرة مثل Facebook و Google ، بالإضافة إلى المواقع الأصغر مثل GitHub ، واجهات برمجة تطبيقات لاستخدام خدماتها لمصادقة المستخدمين. على غرار موفر الدفع ، يؤدي هذا إلى إنشاء سجل في قاعدة البيانات الخاصة بك يربط حسابًا بحساب في قاعدة البيانات الخاصة بهم.

قد ترغب في تضمين المصادقة الاجتماعية في موقعك لتسهيل تسجيل المستخدمين دون إنشاء مجموعة جديدة من بيانات اعتماد تسجيل الدخول. إذا كان تطبيقك يستهدف فقط العملاء الذين يستخدمون بالفعل موقعًا معينًا يوفر خيار المصادقة الاجتماعية ، فقد يساعدك ذلك في جذب المستخدمين من هذا السوق عن طريق تقليل حاجز الدخول. علاوة على ذلك ، إذا كان تطبيقك يعتزم الوصول إلى بيانات المستخدم من خدمة جهة خارجية ، فإن ربط الحسابات أثناء المصادقة يبسط عملية منح الأذونات.

ومع ذلك ، هناك جوانب سلبية لاستخدام المصادقة الاجتماعية. قد تؤدي تغييرات واجهة برمجة التطبيقات أو انقطاعها من مزود الطرف الثالث إلى مقاطعة وقت تشغيل التطبيق أو أنشطة التطوير. بشكل عام ، تضيف التبعيات الخارجية تعقيدًا إلى التطبيق. أخيرًا ، يجدر النظر في جمع البيانات وسياسات الاستخدام الخاصة بالأطراف الثالثة التي تتكامل معها والتأكد من توافقها مع توقعاتك وتوقعات المستخدمين لديك.

إذا قررت أن المصادقة الاجتماعية مناسبة لتطبيقك ، لحسن الحظ ، هناك مكتبة لذلك. Python Social Auth for Django عبارة عن حزمة لتمكين قدرات النظام البيئي للمصادقة الاجتماعية في Python في مشاريع Django.

تغليف

نظرًا لأن حساب المستخدم عالميًا ، يمكن أن يؤدي استخدامه على نطاق واسع إلى حل نفس المشكلات دون داع. نأمل أن تكون هذه المقالة قد أوضحت لك مجموعة الميزات القوية المتوفرة في Django ومنحتك فهمًا للمسؤوليات الأساسية للتطبيق عند إنشاء حسابات مستخدمين.

أضواء جانغو هي سلسلة تقدم مفاهيم مهمة لتطوير الويب في Django. كُتبت كل مقالة كدليل مستقل لأحد جوانب تطوير Django الذي يهدف إلى مساعدة مطوري الواجهة الأمامية والمصممين على الوصول إلى فهم أعمق لـ "النصف الآخر" من قاعدة الكود. تم إنشاء هذه المقالات في الغالب لمساعدتك على فهم النظرية والاتفاقية ولكنها تحتوي على بعض نماذج التعليمات البرمجية ، والتي تمت كتابتها في Django 3.0. سيتم استكشاف العديد من المفاهيم التي تطرقنا إليها في هذه المقالة ، بما في ذلك القوالب والمستخدمين الإداريين والنماذج والنماذج ، بشكل فردي بالتفصيل في المقالات المستقبلية في هذه السلسلة.

أجزاء أخرى في السلسلة:

• يسلط الضوء على Django: قوالب حفظ الخطوط (الجزء الثاني)
• يسلط الضوء على Django: النماذج والمسؤول وتسخير قاعدة البيانات العلائقية (الجزء 3)
• أهم أحداث Django: الأصول الثابتة وملفات الوسائط (الجزء الرابع)