طلب ميزة: السماح بالوصول الآمن إلى إعدادات الموقع عبر واجهة برمجة التطبيقات دون مفتاح على مستوى المسؤول

كما أفهم، فإن اشتراط وصول المسؤول لملف /site/settings.json وبعض المعلومات في /site.json هو سلوك متوقع من Discourse.

تحتاج جسر النقاش (Discussion Bridge) والتكاملات المماثلة إلى مجموعة محدودة من معلومات إعدادات الموقع لتشخيصات روتينية، والتخطيط، والمزامنة. وقد يتطلب ذلك اليوم استخدام مفتاح API مرتبط بمسؤول. يمنع مفتاح المسؤول للقراءة فقط الكتابة، لكنه لا يزال يعرض كل ما يمكن للمسؤول قراءته. ويحمل مفتاح المسؤول العالمي خطرًا كبيرًا بشكل غير ضروري للعمليات الآلية اليومية.

هل يمكن لـ Discourse توفير أي مما يلي:

  • نطاق مفتاح API دقيق يمنح مستخدمي التكامل غير المسؤولين صلاحية القراءة لمجموعة فرعية مناسبة وآمنة من /site.json و /site/settings.json؛ أو
  • نقطة نهاية منفصلة تحتوي على معلومات الإعدادات غير الحساسة التي تحتاجها التكاملات بشكل شائع؟

يدعم Discourse بالفعل مفاتيح API للمستخدمين للمستخدمين العاديين، لكن هذا لا يحل هذه الحالة: لا يمكن للمفتاح ممارسة صلاحيات لا يمتلكها المستخدم المرتبط به بالفعل. لذا، فإن الطلب يتعلق تحديدًا بتفويض آمن غير مسؤول للوصول إلى بيانات إعدادات الموقع المحددة التي تحتاجها التكاملات — وليس مجرد طريقة أخرى لتوليد مفتاح.

الهدف ليس كشف إعدادات المسؤول الخاصة. بل هو السماح لحساب تكامل غير مسؤول مفوض بفحص هيكل الموقع وإعداداته التشغيلية التي يحتاجها دون اشتراط بيانات اعتماد بمستوى المسؤول بشكل روتيني.

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

الخلفية: Confirming API Access to Authoring Limit Site Settings

3 إعجابات

+1 كبير لهذا!

تنضم إلى مؤسستنا أعضاء يحبون أن يكونوا قادرين على المساعدة، ولكن تنفيذ ما عرضوا المساعدة فيه يتطلب منحهم صلاحيات المسؤول. وهذا يجعل من الصعب جداً توفير جميع الميزات والخدمات التي يمكننا تنفيذها بشكل جيد إذا كان لدينا فقط طريقة لتحديد نطاق الصلاحيات والوصول بشكل أكثر دقة. نحتاج إلى أن نكون حذرين للغاية في كيفية منح الصلاحيات لأسباب عديدة، مما يزيد الضغط على المسؤولين للقيام بـ “جميع المهام”، بينما توجد إعدادات موقع غير مدمرة يمكن لبعض أعضاءنا مساعدتنا في إدارتها بسهولة… لكنهم غير قادرين على ذلك.

شكراً لنشر هذا!

إعجابَين (2)

هل يمكنك أن تكون أكثر تحديدًا بشأن إعدادات الموقع الدقيقة؟

يبدو أن منح وصول للقراءة فقط دون قيود إلى جميع إعدادات الموقع أداة قاسية بعض الشيء، وسيتضمن ذلك إعدادات حساسة للغاية بما في ذلك مفاتيح SaaS.

يمكنك إنشاء إضافة تمنح مجموعة وصول للقراءة فقط إلى مجموعة محددة من إعدادات الموقع باسم معين؟

سيكون ذلك إضافة صغيرة نسبيًا.

إعجاب واحد (1)

هل تسألني أم @jenmck؟

[quote=“merefield, post:3, topic:408523”]
يبدو أن منح حق القراءة غير المقيد لجميع إعدادات الموقع أداة قاسية بعض الشيء
[/quote]\nهذا هو الوضع الحالي الناتج عن عدم وجود وصول للمستخدمين غير المسؤولين بالطريقة العادية، ومن هنا جاء طلبي. :slight_smile:

أنت.

لا أفهم ما تقصد :confused: هل يمكنك إعادة الصياغة؟

إعجاب واحد (1)

الهدف هو القيام بعملية التكامل، والوصول إلى الإعدادات المطلوبة وتعديلها دون استخدام مفتاح ذي نطاق عالمي يستخدمه مستخدم مسؤول، أو استخدام مفتاح ذي نطاق محدد بدقة يستخدمه مستخدم مسؤول.
المفتاح ذي النطاق المحدد بدقة أقل فائدة في تقييد الوصول إذا كان لا يزال يتعين عليّ ربطه بمستخدم مسؤول. آمل أن يكون ذلك مفيداً.

اقتراحك باستخدام إضافة هو اقتراح جيد، ومع ذلك لا أريد إضافة بمجموعة الميزات الحالية. لا أريد أن يضطر مستخدم Astro إلى تثبيت إضافة للاتصال بـ Discourse.

ما هو هذا، وما هي الإعدادات التي يحتاج بالتحديد إلى الوصول إليها؟

ما هو مستخدم Astro؟

ليس جاهزًا تمامًا، ولكن بما أنك سألت

SSG

إعجاب واحد (1)

إذن، إذا كنت تبني كل ذلك، فما المشكلة الكبيرة في إنشاء إضافة صغيرة لتقديم بعض الإعدادات للقراءة فقط على مسار مخصص؟

رأيي هو أن سلوك Discourse حول هذا الموضوع يجب تغييره، ومن هنا طلب الميزة. في رأيي، لا يلزم وجود إضافة.

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

لا معنى له بالنسبة لي أيضًا، آسف بسبب هذا التداخل في الكلمات. :grinning_face:

إعجاب واحد (1)