Django-rest-framework: تسرّب صفحة مسؤول الرمز المميز رموز الوصول إلى ملفات السجل

موافق. نعم. ليست مثالية.

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

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

أعتقد أن هذا ليس صحيحًا بالنسبة للأشخاص الذين سيستخدمون / يجب أن يستخدموا التنفيذ المقدم في الإنتاج.
(في هذه الحالات سيكونان نفس الشخص).

لست متأكدًا مما قد يقوله الآخرون ...

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

أحصل على هذا المنصب ، ولكن بعد ذلك يجب على المستندات أن توصي المستخدمين بشدة بعيدًا عن التنفيذ المدمج على الأقل ، والإهمال في النهاية القصوى للأشياء. توصية الطرف الثالث لمصادقة الرمز / التوقيع هي https://github.com/etoccalino/django-rest-framework-httpsignature والتي لم يتم تحديثها منذ 3 سنوات. أتخيل أنه سيكون هناك الكثير من الاهتمام بموفري الرموز من الأطراف الثالثة إذا لم يتم توفير أي منهم خارج الصندوق.

يعد هذا الكشف IMO خطيرًا جدًا ، لذلك لست متأكدًا من أن الموضع الافتراضي لـ authtoken هو الطريقة الصحيحة للذهاب في هذه الحالة.

لا ، ولهذا لم أغلقه ...

آسف إذا جاء ردي أكثر قسوة مما هو مقصود ، لم يكن هذا هدفي.

لا مشاكل! 😃

(أتساءل عما إذا كان بإمكاننا استخدام ModelAdmin لاستخدام تجزئة المفتاح في عنوان url ...)

متستر ، لكن هذه الفكرة تبدو خطيرة أيضًا ، رغم أنني لا أستطيع أن أقول السبب.

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

لا أعتقد أنني حاولت ترحيل حقول المفاتيح الأساسية من قبل ، لكن يبدو أنني أتذكر أن هناك عملية تتعامل معها ، وتحديثات المفتاح الخارجي المقابلة أيضًا.

نعم. سيحتاج إلى ترحيل بيانات ، لكن بخلاف ذلك أعتقد أنه سهل بما يكفي للتبديل.

نرحب بطلبات السحب. شكرا على التقرير!

هل يجب أن يكون الرمز المميز فريدًا بالضرورة؟

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

أتساءل عما إذا كان من الممكن إضافة حقل عدد صحيح زيادة تلقائية في جدول الرمز المميز والذي يتم استخدامه كمرجع داخل صفحة إدارة Django لرمز Auth ، ولكن ليس كمفتاح أساسي للجدول؟

لمعلوماتك ، لقد تحققت للتو من أن لدي أيضًا نفس المشكلة مع تطبيق الرمز المميز الخاص بي (انظر django-rest-multitokenauth ) - لذا نشكرك على الإشارة إلى هذا الخطأ في لوحة المسؤول! أنا أتطلع لرؤية الحل هنا ، حتى أتمكن من تعديل حزمة بايثون الخاصة بي.

لمعلوماتك ، هذه هي الطريقة التي أصلحتها في حزمة MultiTokenAuth الخاصة بي:
https://github.com/anx-ckreuzberger/django-rest-multiauthtoken/commit/7e11ed606271eff0693a9280f8a30349c7e90b27

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

مرحبا،

كنت أقوم بتصفح المشكلات المتعلقة بالمصادقة قبل تقييم هذه المكتبة لمشروع قادم. لدي سؤال بسيط ، أقدر أي مساعدة.

هل يمكن تجنب هذه المشكلة بمجرد عدم تسجيل نموذج الرمز المميز في المسؤول؟

raunaqss نعم ، لست بحاجة إلى تسجيله.

شكرا لإعادة رفع هذا.

هل نعرف ما هي الطريقة التي نسير بها مع هذا؟
هل يجب تجزئة عنوان url أم ترحيل pk؟

يمكنني تقديم العلاقات العامة.

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

دعونا نلقي نظرة على تحرير الترحيل لهذا بشكل منفصل ، بدلاً من دفعه في الإصدار 3.11 نفسه. أنا حذر جدًا من الآثار المترتبة على المستخدمين الذين لديهم جداول مفاتيح API كبيرة جدًا لدفع الترحيل على جميع مستخدمينا في إصدار رئيسي.

ظلت هذه المشكلة مفتوحة لفترة طويلة ، وعلى الرغم من أن django-rest- knox يبدو أن ملاحظةjarshwah قد تمت معالجتها ، فربما نريد أن نكون أكثر أمانًا بشكل افتراضي. حتى لو كانت نية TokenAuthentication أن يكون الأمر بسيطًا ، فإن العديد من المطورين ملزمون بتنفيذ آلية مصادقة غير آمنة. لست متأكدًا من أن الكود الذي يسرب المواد السرية حسب التصميم يجب إدراجه خارج الصندوق.

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

سأقوم بتخصيصه مسبقًا لـ 3.12.

سأكون مهتمًا بالمساهمة في الكود

مرحبًا جدًا بإصدار PR لذلك ، بالتأكيد.

سأكون مهتمًا بالمساهمة في الكود أو دفع مكافأة إذا كان الأمر كذلك.

أن تصبح راعيا هو وسيلة جيدة للمساهمة. يتمتع الرعاة بالدعم ذي الأولوية ويمكنهم تقديم أي مشكلة إذا لزم الأمر. https://fund.django-rest-framework.org/topics/funding/#corporate -plans

كل هذا يبدو رائعًا! أنا الآن راعي drf والتشفير. سأكون على يقين من تحديث هذه المشكلة إذا / عندما أبدأ العمل على حل.

رائع ، شكرا جزيلا لك. 🙏

حسنًا ، ليس من الواضح حقًا كيفية التعامل مع هذا بأمان.

نود حقًا أن يستخدم النموذج زيادة تلقائية للمفتاح الأساسي ، وأن يكون حقل "المفتاح" حقلاً قياسيًا فريدًا ومفهرسًا ، لكن لا يمكننا الترحيل إلى ذلك. فما هي خياراتنا...

• يمكننا تقديم شيء مثل rest_framework.authtoken2 وجعل المستندات تشير إلى ذلك بدلاً من ذلك ، حتى تحصل المشاريع الجديدة على مجموعة أفضل من الإعدادات الافتراضية.
• يمكننا الاستمرار في استخدام الحقل الحالي كـ PK ، وإضافة حقل جديد لقيمة الرمز المميز الفعلية. ليس من الواضح ما إذا كان بإمكاننا تقديم ترحيل البيانات بنسخ القيم عبر ، كما قد يحدث؟ تكون إشكالية للمستخدمين الذين لديهم مجموعات بيانات كبيرة موجودة. يبدو هذا لائقًا ... https://stackoverflow.com/questions/41500811/copy-a-database-column-into-another-in-django سنحتاج أيضًا إلى توخي الحذر الشديد بشأن استمرار السلوك الصحيح لقواعد الرموز غير المهاجرة. إذا كنا نعمل على تطبيق تم نشره ، فسنرغب عادةً في البدء بتقديم الحقل الجديد ، والتأكد من أننا نكتب نفس القيم لكلا الحقلين مع استمرار وجود قاعدة بيانات تشير إلى الحقل القديم لفترة من الوقت. وفقط مرة واحدة يتم نشرها ومزامنتها بالكامل ، قم بإدخال تبديل تغيير الكود إلى استخدام الحقل الجديد.
• يمكننا الاستمرار كما نحن ولكن نقدم بعض التغييرات الإدارية.

هل لدى أي شخص أي أفكار أولية حول هذا؟

أيضًا: لهذا السبب ظل هذا الأمر معلقًا لفترة طويلة - لا توجد إجابة سهلة عليه. 😬

فتحت رقم 7341 لإلقاء نظرة على خيار _ "إدخال بعض التغييرات الإدارية" _.