أضرار تغيير الـ SECRET_KEY في مشروع جانغو Django

يتم استخدام SECRET_KEY في العديد من الأماكن المختلفة في مشروغ جانغو Django، وسأوضح ما التأثيرات و الأضرار التي قد تحدث إذا قمت بتغيير الـ SECRET_KEY.

قائمة الأشياء التي تستخدم SECRET_KEY بشكل مباشر أو غير مباشر:

• JSON object signing

• دوال التشفير لـ salted hmacs أو دعم محرك توليد النصوص والأرقام العشوائية الذي يؤثر على كل من:

  • توليد رمز إعادة تعين كلمات السر password reset token (للمستخدمين والمسؤولين)

  • comment form security: لحماية الموقع من طلبات POST من مواقع غريبة

  • form security: حماية النماذج بشكل عام

  • message tampering، لأنه قد يستخدم ملفات الكوكيز Cookis لنقل البيانات بين ملفات العرض views

  • حماية الجلسات session data  وعمل مفاتيح عشوائية للجلسات session keys 

  • توليد random salt من أجل إستخدامها في دوال الهاش password hashers

  • توليد كلمات مرور عشوائية passwords، إذا تطلب الأمر

  • عمل مفتاح CSRF

ما سوف يتغير عند المستخدم بشكل مباشر عند تغيير قيمة SECRET_KEY هي:

• الجلسات، سيتم كسر فك تشفير البيانات، وهو صالح لأي خلفية جلسة (ملفات تعريف الارتباط أو قاعدة البيانات أو الملفات المستندة إلى ذاكرة التخزين المؤقت).

• لن يعمل رمز إعادة تعيين كلمة المرور الذي تم إرساله بالفعل لأي مستخدم، وسيتعين على المستخدمين طلب رمز جديد.

• لن يتم التحقق من صحة نموذج التعليقات (في حالة استخدام django.contrib.comments) إذا تم طلبه قبل تغيير القيمة (أي إذا تم تحمليه في المتصفح ثم تم تغير الـ SECRET_KEY) وتقديمه بعد تغيير القيمة. أعتقد أن هذا بسيط جدًا ولكنه قد يكون مربكًا للمستخدم.

• الرسائل (من django.contrib.messages) لن تتحقق من جانب الخادم مثل نموذج التعليقات.

بداية من جانغو Django الإصدار 1.10 يمكنك توليد SECRET_KEY جديد من خلال دالة get_random_secret_key على النحو التالي:

./manage.py shell -c "from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())"