إنتقل إلى المحتوى الرئيسي

RPC العام بدون إذن

تقوم هذه الصفحة بتأطير RPC العام باعتباره اقتراح Bitsocial على مستوى المنتج بدلاً من جدار تفاصيل التنفيذ.

هدف باللغة البسيطة​

يمكن لـ Bitsocial Forge تشغيل خدمة RPC عامة تتيح للعديد من المستخدمين إدارة مجتمعات Bitsocial الخاصة بهم عن بعد، دون تحويل المشغل إلى حارس لتلك المجتمعات.

يجب أن تجعل الخدمة العملاء المتنقلين وخفيفي الوزن عمليين مع الحفاظ على ثلاثة قيود:

  1. يظل المستخدمون معزولين عن بعضهم البعض بشكل افتراضي.
  2. تظل الأذونات صريحة ومفصلة.
  3. يمكن الحفاظ على التوافق مع طلب RPC الحالي وشكل الاستجابة أثناء الطرح.

ما هي المشكلة التي يحلها​

اليوم، عادةً ما يكون أبسط نموذج RPC هو الكل أو لا شيء: مفتاح مصادقة واحد، مجال سلطة واحد، وصول كامل. يعمل هذا مع مشغل واحد ولكن ليس مع خدمة عامة متعددة المستخدمين.

يحتاج RPC العام غير المسموح به إلى نموذج أقوى:

  • يمكن لخدمة واحدة استضافة العديد من المستخدمين
  • يحصل كل مستخدم على مجتمعاته وحدوده الخاصة
  • يمكن للسياسات التي يحددها المشغل أن تمنع إساءة الاستخدام
  • لا يزال بإمكان المستخدم الابتعاد أو الاستضافة الذاتية لاحقًا

النموذج الأساسي​

المستخدمين​

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

المجتمعات​

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

الأذونات​

تعتمد الأذونات على القدرة. بدلاً من قيمة منطقية واحدة لـ "يمكن استخدام RPC"، يمكن للخادم التحكم في:

  • عدد المجتمعات التي يمكن للمستخدم إنشاؤها
  • ما هي طرق الإدارة المتاحة
  • ما هي عمليات النشر المسموح بها
  • ما هي حدود المعدل المطبقة
  • ما هي الأسطح الإدارية مرئية

سطح المشرف​

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

موقف التوافق​

يجب أن تستخدم الوثائق التي تواجه المستخدم مصطلحات Bitsocial مثل community و profile.

على مستوى السلك، لا يزال بإمكان الطرح الأول الحفاظ على شكل النقل والحمولة الحالي لـ JSON-RPC حيث يكون ذلك مفيدًا للتوافق. بمعنى آخر: يمكن أن تظل المستندات أصلية على Bitsocial حتى لو احتفظت الفترة الانتقالية ببعض أسماء الطرق الموجهة نحو التوافق أو أشكال الطلب خلف الكواليس.

حزمة الأذونات المقترحة​

type PermissionBundle = {
  maxCommunities: number; // 0 = unlimited
  methods: {
    createCommunity: boolean;
    startCommunity: boolean;
    stopCommunity: boolean;
    editCommunity: boolean;
    deleteCommunity: boolean;
    publishComment: boolean;
    publishVote: boolean;
    publishCommentEdit: boolean;
    publishCommentModeration: boolean;
    publishCommunityEdit: boolean;
    getComment: boolean;
    getCommentPage: boolean;
    getCommunityPage: boolean;
    fetchContent: boolean;
    resolveAuthorAddress: boolean;
    commentUpdateSubscribe: boolean;
    communityUpdateSubscribe: boolean;
    communityListSubscribe: boolean;
    settingsSubscribe: boolean;
  };
  rateLimits: {
    requestsPerMinute: number;
    publishesPerHour: number;
  };
  storage: {
    maxTotalSize: number;
  };
  scope: {
    canPublishExternal: boolean;
    canReadExternal: boolean;
  };
  admin: {
    canTransferOwnership: boolean;
    canManageUsers: boolean;
    canViewAuditLogs: boolean;
    canViewAllCommunities: boolean;
  };
};

أسماء الطريقة الدقيقة توضيحية. الجزء المهم هو شكل السياسة: يتم التحكم في القدرات الفردية بشكل مستقل بدلاً من تجميعها في رمز مستخدم متميز واحد.

تدفق الاتصال​

client connects with auth credential
-> server validates the credential
-> server loads the user's permission bundle
-> server returns a permissions notification
-> client proceeds with the subset of actions it is allowed to use

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

إنفاذ الملكية​

عندما تقوم الخدمة بإنشاء مجتمع، يجب أن تقوم تلقائيًا بتعيين الملكية للمستخدم المتصل. من هناك:

  • إجراءات بدء المجتمع وإيقافه وتحريره وحذفه تخضع لنطاق المالك
  • استجابات القائمة والاشتراك افتراضية لمجتمعات المتصل الخاصة
  • إن الرؤية الأوسع هي إذن إداري صريح، وليس افتراضيًا

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

سطح المشغل المقترح​

يمكن أن تظل واجهة برمجة تطبيقات المشرف مملة وصريحة:

  • قائمة المستخدمين
  • فحص مستخدم واحد
  • إنشاء أو تحديث المستخدمين
  • حذف المستخدمين
  • نقل ملكية المجتمع
  • فحص سجلات التدقيق

يجب أن تكون المصادقة الخاصة بواجهة برمجة تطبيقات المشغل هذه منفصلة تمامًا عن مصادقة RPC للمستخدم النهائي.

مراحل الطرح​

المرحلة 1​

  • إنشاء هيكل مشروع RPC العام
  • إضافة سجلات المستخدم وتتبع الملكية
  • شوكة أو توسيع خادم RPC الحالي

المرحلة 2​

  • تنفيذ حزم الأذونات
  • فرضها في طبقة أسلوب RPC
  • إرجاع البيانات التعريفية للأذونات عند الاتصال

المرحلة 3​

  • أضف واجهة برمجة تطبيقات المشغل
  • إضافة تسجيل التدقيق
  • إضافة مصادقة المسؤول

المرحلة 4​

  • شحن لوحة تحكم المشرف
  • ضوابط إساءة الاختبار
  • تشديد تحديد المعدل وحصص التخزين

أسئلة مفتوحة​

مصادقة البريد العشوائي لبيانات الاعتماد​

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

تفاصيل الهجرة​

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

ملخص​

يدور هذا الاقتراح في الواقع حول شيء واحد: جعل البنية التحتية العامة لـ RPC مفيدة دون جعلها خاضعة للرقابة. يجب أن تبدو خدمة Bitsocial RPC العامة الجيدة وكأنها مساعدة اختيارية لإدارة المجتمعات، وليس مثل منصة مركزية جديدة تستعيد الملكية من الباب الخلفي.