كما أفهم، فإن اشتراط وصول المسؤول لملف /site/settings.json وبعض المعلومات في /site.json هو سلوك متوقع من Discourse.
تحتاج جسر النقاش (Discussion Bridge) والتكاملات المماثلة إلى مجموعة محدودة من معلومات إعدادات الموقع لتشخيصات روتينية، والتخطيط، والمزامنة. وقد يتطلب ذلك اليوم استخدام مفتاح API مرتبط بمسؤول. يمنع مفتاح المسؤول للقراءة فقط الكتابة، لكنه لا يزال يعرض كل ما يمكن للمسؤول قراءته. ويحمل مفتاح المسؤول العالمي خطرًا كبيرًا بشكل غير ضروري للعمليات الآلية اليومية.
هل يمكن لـ Discourse توفير أي مما يلي:
نطاق مفتاح API دقيق يمنح مستخدمي التكامل غير المسؤولين صلاحية القراءة لمجموعة فرعية مناسبة وآمنة من /site.json و /site/settings.json؛ أو
نقطة نهاية منفصلة تحتوي على معلومات الإعدادات غير الحساسة التي تحتاجها التكاملات بشكل شائع؟
يدعم Discourse بالفعل مفاتيح API للمستخدمين للمستخدمين العاديين، لكن هذا لا يحل هذه الحالة: لا يمكن للمفتاح ممارسة صلاحيات لا يمتلكها المستخدم المرتبط به بالفعل. لذا، فإن الطلب يتعلق تحديدًا بتفويض آمن غير مسؤول للوصول إلى بيانات إعدادات الموقع المحددة التي تحتاجها التكاملات — وليس مجرد طريقة أخرى لتوليد مفتاح.
الهدف ليس كشف إعدادات المسؤول الخاصة. بل هو السماح لحساب تكامل غير مسؤول مفوض بفحص هيكل الموقع وإعداداته التشغيلية التي يحتاجها دون اشتراط بيانات اعتماد بمستوى المسؤول بشكل روتيني.
هذا سيقلل من خطر بيانات الاعتماد، ويدعم التكاملات بأقل امتيازات ممكنة، ويجعل أدوات الآلة إلى الآلة المستدامة أسهل في التشغيل بأمان.
تنضم إلى مؤسستنا أعضاء يحبون أن يكونوا قادرين على المساعدة، ولكن تنفيذ ما عرضوا المساعدة فيه يتطلب منحهم صلاحيات المسؤول. وهذا يجعل من الصعب جداً توفير جميع الميزات والخدمات التي يمكننا تنفيذها بشكل جيد إذا كان لدينا فقط طريقة لتحديد نطاق الصلاحيات والوصول بشكل أكثر دقة. نحتاج إلى أن نكون حذرين للغاية في كيفية منح الصلاحيات لأسباب عديدة، مما يزيد الضغط على المسؤولين للقيام بـ “جميع المهام”، بينما توجد إعدادات موقع غير مدمرة يمكن لبعض أعضاءنا مساعدتنا في إدارتها بسهولة… لكنهم غير قادرين على ذلك.
[quote=“merefield, post:3, topic:408523”]
يبدو أن منح حق القراءة غير المقيد لجميع إعدادات الموقع أداة قاسية بعض الشيء
[/quote]\nهذا هو الوضع الحالي الناتج عن عدم وجود وصول للمستخدمين غير المسؤولين بالطريقة العادية، ومن هنا جاء طلبي.
الهدف هو القيام بعملية التكامل، والوصول إلى الإعدادات المطلوبة وتعديلها دون استخدام مفتاح ذي نطاق عالمي يستخدمه مستخدم مسؤول، أو استخدام مفتاح ذي نطاق محدد بدقة يستخدمه مستخدم مسؤول.
المفتاح ذي النطاق المحدد بدقة أقل فائدة في تقييد الوصول إذا كان لا يزال يتعين عليّ ربطه بمستخدم مسؤول. آمل أن يكون ذلك مفيداً.
اقتراحك باستخدام إضافة هو اقتراح جيد، ومع ذلك لا أريد إضافة بمجموعة الميزات الحالية. لا أريد أن يضطر مستخدم Astro إلى تثبيت إضافة للاتصال بـ Discourse.
رأيي هو أن سلوك Discourse حول هذا الموضوع يجب تغييره، ومن هنا طلب الميزة. في رأيي، لا يلزم وجود إضافة.
لدي حل بديل بدون الإضافة، لذا فإن الأمور تعمل albeit بطريقة أقل تفضيلًا. أما بالنسبة للإضافة، فهي قادمة ولكن لمجموعة إضافية من الميزات القابلة للتكوين داخل الإضافة.
لا معنى له بالنسبة لي أيضًا، آسف بسبب هذا التداخل في الكلمات.