پرش به مطلب اصلی

RPC عمومی بدون مجوز

این صفحه RPC عمومی را به عنوان یک پیشنهاد Bitsocial در سطح محصول به جای دیواری از جزئیات پیاده سازی قاب بندی می کند.

هدف به زبان ساده​

Bitsocial Forge می‌تواند یک سرویس RPC عمومی را اجرا کند که به بسیاری از کاربران اجازه می‌دهد تا جوامع Bitsocial خود را از راه دور مدیریت کنند، بدون اینکه اپراتور را به نگهبان آن جوامع تبدیل کند.

این سرویس باید با حفظ سه محدودیت، مشتریان سیار و سبک وزن را کاربردی کند:

  1. کاربران به طور پیش فرض از یکدیگر جدا می مانند.
  2. مجوزها صریح و جزئی باقی می مانند.
  3. سازگاری با درخواست RPC فعلی و شکل پاسخ را می توان در طول عرضه حفظ کرد.

چه مشکلی را حل می کند​

امروزه، ساده ترین مدل RPC معمولاً همه یا هیچ است: یک کلید تأیید، یک دامنه مرجع، دسترسی کامل. این برای یک اپراتور منفرد کار می کند اما برای یک سرویس چند کاربره عمومی نه.

یک RPC عمومی بدون مجوز به مدل قوی تری نیاز دارد:

  • یک سرویس می تواند میزبان کاربران زیادی باشد
  • هر کاربر جوامع و محدودیت های خود را دارد
  • سیاست های تعریف شده توسط اپراتور می تواند از سوء استفاده جلوگیری کند
  • کاربر همچنان می تواند از آنجا خارج شود یا بعداً میزبان خود باشد

مدل هسته​

کاربران​

هر کاربر یک اعتبار تأیید اعتبار به همراه یک بسته مجوز دریافت می کند.

جوامع​

جوامع ایجاد شده از طریق این سرویس به یک سابقه مالک اختصاص داده می شوند. مالکیت به صراحت پیگیری می شود تا بتوان روش های مدیریتی را به کاربر مناسب تقسیم کرد.

مجوزها​

مجوزها مبتنی بر قابلیت هستند. به جای یک بولی برای "می توان از RPC استفاده کرد"، سرور می تواند کنترل کند:

  • یک کاربر چند انجمن می تواند ایجاد کند
  • کدام روش های مدیریتی موجود است
  • چه عملیات انتشار مجاز است
  • چه محدودیت های نرخ اعمال می شود
  • چه سطوح مدیریت قابل مشاهده است

سطح مدیریت​

خود RPC عمومی باید روی رفتار RPC رو به روی کاربر متمرکز بماند. وظایف اداری مانند ایجاد کاربر، انتقال مالکیت و بررسی حسابرسی متعلق به یک API و داشبورد اپراتور جداگانه است.

موضع سازگاری​

در اسناد رو به رو کاربر باید از اصطلاحات Bitsocial مانند community و profile استفاده شود.

در سطح سیم، اولین عرضه همچنان می‌تواند شکل JSON-RPC و حمل و نقل فعلی را حفظ کند، جایی که برای سازگاری مفید است. به عبارت دیگر: اسناد می‌توانند به صورت Bitsocial-Native باقی بمانند، حتی اگر دوره انتقال برخی از نام‌های متد سازگار محور یا درخواست شکل‌ها را در پشت صحنه نگه دارد.

بسته مجوز پیشنهادی​

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

آگاهی از مجوز باید اختیاری بماند. سرویس گیرنده ای که اعلان را نادیده می گیرد، همچنان می تواند با رسیدگی به خطاهای مجوز استاندارد از سرور، به درستی رفتار کند.

اجرای مالکیت​

هنگامی که سرویس یک انجمن ایجاد می کند، باید به طور خودکار مالکیت را به کاربر تماس گیرنده اختصاص دهد. از آنجا:

  • فعالیت‌های شروع، توقف، ویرایش و حذف انجمن با محدوده مالک هستند
  • لیست و پاسخ های اشتراک به طور پیش فرض برای جوامع خود تماس گیرنده است
  • دید گسترده‌تر یک مجوز صریح مدیر است، نه پیش‌فرض

یک مورد لبه اهمیت زیادی دارد: اگر کاربر در انجمنی مشترک شود که او نیست آن را ندارد، سرور فقط باید وضعیت عمومی را که هر ناظر خارجی باید ببیند، در معرض دید قرار دهد. پیکربندی فقط مالک یا داده‌های زمان اجرا داخلی هرگز نباید از طریق API اشتراک درز کند.

سطح اپراتور پیشنهادی​

Admin API می تواند خسته کننده و واضح بماند:

  • لیست کاربران
  • یک کاربر را بازرسی کنید
  • ایجاد یا به روز رسانی کاربران
  • کاربران را حذف کنید
  • انتقال مالکیت جامعه
  • گزارش های حسابرسی را بازرسی کنید

احراز هویت برای این اپراتور API باید کاملاً از تأیید اعتبار RPC کاربر نهایی جدا باشد.

مراحل عرضه​

فاز 1​

  • ساختار پروژه عمومی RPC را ایجاد کنید
  • سوابق کاربر و ردیابی مالکیت را اضافه کنید
  • انشعاب یا گسترش سرور RPC فعلی

فاز 2​

  • پیاده سازی بسته های مجوز
  • آنها را در لایه روش RPC اجرا کنید
  • برگرداندن فراداده مجوزها در اتصال

فاز 3​

  • API اپراتور را اضافه کنید
  • اضافه کردن گزارش حسابرسی
  • احراز هویت ادمین را اضافه کنید

فاز 4​

  • داشبورد مدیریت را ارسال کنید
  • تست های کنترل سوء استفاده
  • محدودیت نرخ و سهمیه ذخیره سازی را تشدید کنید

سوالات باز​

تأیید اعتبار هرزنامه​

اگر ایجاد احراز هویت ارزان باشد، خدمات عمومی ممکن است قبل از صدور اعتبارنامه به یک لایه چالشی نیاز داشته باشند. یکی از راه‌های ممکن، استفاده مجدد از خود مدل چالش جامعه است، بنابراین صدور اعتبارنامه همان فلسفه ضد سوء استفاده بقیه شبکه را به ارث می‌برد.

جزئیات مهاجرت​

برخی از پیاده‌سازی‌های اولیه ممکن است هنوز نام روش‌های سازگاری گرا را به صورت داخلی نشان دهند. این باید به عنوان یک جزئیات مهاجرت در نظر گرفته شود، نه به عنوان واژگان عمومی دائمی اسناد Bitsocial.

خلاصه​

این پیشنهاد واقعاً در مورد یک چیز است: مفید ساختن زیرساخت RPC عمومی بدون اینکه آن را نگهبانی کند. یک RPC عمومی Bitsocial خوب باید مانند کمک اختیاری برای اجرای جوامع احساس شود، نه مانند یک پلت فرم مرکزی جدید که مالکیت را از در پشتی پس می گیرد.