عذرًا على المنشور القديم، لكن لماذا لا تقوم بإعداد نسختك من القالب كـ مستودع على GitHub؟ امنح فريق التصميم وتجربة المستخدم صلاحية الوصول لتحديث القالب على GitHub.
في Discourse، يمكنك الآن إعداد القوالب للتحديث التلقائي عند إعادة البناء.
سيحتاج المسؤولون الآن فقط إلى إعادة البناء لجلب أي تغييرات يقوم بها فريق التصميم وتجربة المستخدم، ولن يحتاج الأخير إلى أي صلاحية إدارية على الإطلاق.
ملاحظة قصيرة:
عند التعامل مع مسائل التحكم في الوصول في البرمجة، يجب إجراء فحوصات RBAC هذه بشكل عام على جانب الخادم.
يمكن التلاعب بأكواد RBAC في جافا سكريبت من جانب العميل بواسطة العميل نفسه.
هذا يعني أنه عند تحديد أذونات RBAC الأساسية للموظفين والمشرفين والمعدلين، يجب القيام بذلك (بشكل عام) في Rails، وليس في جافا سكريبت.
بالمناسبة، هذا هو الطريقة التي يتبعها Discourse الآن في تطبيق RBAC، باستخدام ما يسميه Discourse “Guardian”، وهو فئة Ruby تُسمى class Guardian، هنا:
إذا كان المطور ينوي إضافة فحوصات RBAC في كود جافا سكريبت عن طريق استدعاء واجهة برمجة تطبيقات Discourse، فيجب أن يضع في اعتباره أن هذا الكود قد يتعرض للخطر لأن الكود الذي يعمل في المتصفح يمكن التلاعب به.
توصيتي هي التأكد من تنفيذ جميع أكواد RBAC الأساسية على جانب الخادم، وعدم محاولة اختصار هذه العملية في كود جافا سكريبت من جانب العميل.
هناك أيضًا مستوى ثقة 4 ومشرفو الفئات، في Discourse 2.5 وما بعده.
لدي حالة استخدام مشابهة، حيث أدير مجتمعًا غير ربحي صغيرًا، ويقوم أحد مستخدمينا بصيانة السمات والتصميم.
لا أرغب في منح أي شخص غيري وشريك الملكية الوصول إلى بيانات المستخدمين الخاصة (مثل عناوين البريد الإلكتروني وما إلى ذلك)، لكن لدي 4 مشرفين.
من أجل تمكين المصمم من العمل، اضطرت لإنشاء موقع نسخة بدون محتوى ليكون هو المدير فيه، ثم أقوم بنسخ السمات والمكونات يدويًا. ومع ذلك، فإن هذا غير مرغوب فيه لأن بعض التغييرات تتطلب محتوى لإثباتها.
لماذا لا تضيف بعض المحتوى إلى موقع المرحلة التجريبية / الاختبار؟ هذه هي التوصية النموذجية.
لذا، دع المطور يعمل على موقع الاختبار (staging) ويدفع السمات إلى GitHub. لكنك ستظل بحاجة إلى ترقيتها بنفسك. قد تتمكن من إجراء الترقية باستخدام واجهة برمجة التطبيقات (API) وجعل المطور قادرًا على تشغيلها بطريقة ما.
أعمل حاليًا على أداة قد تكون قادرة على المساعدة في ذلك.
لدينا هذه الحاجة بالضبط أيضًا، هل قام أي شخص بحلها بالصدفة؟
لا أعرف ما إذا كان هذا مفيدًا في هذا الموقف، ولكن إذا كنت تحتاج فقط إلى بعض المحتوى، فهناك مهمة populate في rake:
شكرًا لك، للأسف ليس مفيدًا حقًا في الوقت الحالي.
إذا كنت لا تثق في المصمم لرؤية بياناتك، فما هو الحل الذي تتخيله؟
هل يمكنك فقط تزويدهم بمفتاح API يسمح لهم باستخدام discourse_cli لدفع السمة إلى هناك، ثم تعطيله عندما ينتهون، ربما؟
لا يوجد سبب على الإطلاق لأن يتمكن المصمم من الوصول إلى 100 ألف مستخدم هههه. علاوة على ذلك، سيكون ذلك ضد قواعد اللائحة العامة لحماية البيانات. هل من الممكن إعطاء مفتاح سطر أوامر لتحديثات السمات فقط؟
عذراً! أعتقد أنك على حق.
الآن، على عكس وقت إنشاء هذا الموضوع (والذي يبدو أنه كان المكان الذي كان فيه عقلي عندما كتبت ردي)، لدينا بالفعل مفاتيح API مفصلة. لا ينبغي أن يكون من الصعب إضافة نطاق جديد فقط لإدارة السمات.
قد يكون من المفيد إنشاء موضوع جديد في Feature للمطالبة بنطاق مفتاح API لمطور السمات. تبدو هذه فكرة جيدة.
لا، ليس كذلك. قد يكون ضد قواعد ذلك الموقع، ولكن يمكن ويجب تغييرها.
سيكون من الجيد لو تمكن @AV_C من نشر مرجع لهذا المتطلب. على الرغم من أنني أقدر بشدة سبب رغبة العميل في تقييد الوصول إلى قاعدة المستخدمين وحتى الفئات الخاصة لأسباب متنوعة. يمكن للمسؤول الكامل الوصول إلى رسائل البريد الإلكتروني لتسجيل الأعضاء وقد تحتوي الفئات الخاصة على محتوى حساس آخر اعتمادًا على حالة استخدام العميل.
أعتقد أن @pfaffman لديه فكرة جيدة لضمان تغطية هذا النوع من الثغرات من خلال واجهة برمجة تطبيقات مسؤول مقيدة. بمجرد اكتمال عمل المصمم، يمكن إلغاء المفتاح حتى الحاجة إليه.
سيتناسب هذا أيضًا مع فكرة جاي بعدم إظهار المستخدم كمسؤول في صفحة “حول”.