يعد تعيين أذونات المستخدم جزءًا شائعًا في معظم مشاريع Django ويمكن أن يصبح معقدًا جدًا مع توسع المشروع.
سنستخدم مثال تطبيق المدونة حتى نفهم العملية بوضوح.
المثال هو مدونة بها حسابات مستخدمين ولكن بدون أذونات. فكيف يمكننا إضافة البعض؟
Views
بشكل عام يتم تعيين الأذونات في ملف views.py و تبدو طريقة العرض الحالية لتحديث منشور مدونة موجود BlogUpdateView ، على النحو التالي:
# blog/views.py
class BlogUpdateView(UpdateView):
model = Post
template_name = 'post_edit.html'
fields = ['title', 'body']
LoginRequired
لنفترض الآن أننا نريد تسجيل دخول المستخدم قبل أن يتمكن من الوصول إلى BlogUpdateView.
هناك طرق متعددة للقيام بذلك ولكن أبسطها في رأيي ، هو استخدام LoginRequiredMixin المدمجة.
يتم استدعاؤها بالترتيب من اليسار إلى اليمين ، لذا سنرغب في إضافة mixin لتسجيل الدخول قبل UpdateView. و هذا يعني أنه إذا لم يقم المستخدم بتسجيل الدخول فسيرى رسالة خطأ.
# blog/views.py
from django.contrib.auth.mixins import LoginRequiredMixin
class BlogUpdateView(LoginRequiredMixin, UpdateView):
model = Post
template_name = 'post_edit.html'
fields = ['title', 'body']
UserPassesTestMixin
أذونات المستوى التالي هي شيء خاص بالمستخدم و على وجه التحديد دعونا نفرض القاعدة القائلة بأن مؤلف منشور المدونة هو الوحيد الذي يمكنه تحديثه.
ولذلك سنحتاج إلى خاصية مدمجة تسمى UserPassesTestMixin .
# blog/views.py
from django.contrib.auth.mixins import LoginRequiredMixin, UserPassesTestMixin
class BlogUpdateView(LoginRequiredMixin, UserPassesTestMixin, UpdateView):
model = Post
template_name = 'post_edit.html'
fields = ['title', 'body']
def test_func(self):
obj = self.get_object()
return obj.author == self.request.user
لاحظ أننا قمنا بإستراد UserPassesTestMixin في الأعلى و قمنا بإضافته في المرتبة الثانية في قائمة mixins الخاصة بنا لـ BlogUpdateView. و هذا يعني أنه يجب على المستخدم تسجيل الدخول أولاً ومن ثم يجب عليه اجتياز اختبار المستخدم قبل الوصول إلى UpdateView.
هل يمكننا وضع UserPassesTestMixin أولاً؟ نعم ، ولكن من الأفضل بشكل عام أن تبدأ بالأذونات الأكثر عمومية ثم تصبح أكثر دقة كلما تقدمت إلى اليمين.
يتم استخدام طريقة test_func بواسطة UserPassesTestMixin لمنطقنا و نحن بحاجة إلى تجاوزه.
في هذه الحالة قمنا بتعيين المتغير obj على الكائن الحالي الذي تم إرجاعه بواسطة العرض باستخدام get_object.
فإذا كان المؤلف الموجود على الكائن الحالي يطابق المستخدم الحالي على صفحة الويب (من قام بتسجيل الدخول ويحاول إجراء التغيير) ، فسيتم السماح بذلك. أما في حالة العكس فسيتم طرح خطأ.
هناك طرق أخرى لتعيين أذونات لكل مستخدم بما في ذلك تجاوز طريقة الإرسال ولكن UserPassesTestMixin مصممة خصيصًا لحالة الاستخدام هذه.