Загальнодоступний RPC без дозволу

Оригінальна публічна пропозиція RPC існувала як випуск GitHub, написаний старою термінологією плебіта. Ця сторінка переписує цю ідею мовою Bitsocial і оформляє її як пропозицію на рівні продукту замість стіни деталей впровадження.

Мета простою мовою

Bitsocial Forge може запускати загальнодоступну службу RPC, яка дозволяє багатьом користувачам віддалено керувати власними спільнотами Bitsocial, не перетворюючи оператора на опікуна цих спільнот.

Послуга повинна зробити мобільних і легких клієнтів практичними, зберігаючи при цьому три обмеження:

1. За замовчуванням користувачі залишаються ізольованими один від одного.
2. Дозволи залишаються чіткими та детальними.
3. Сумісність із поточним запитом RPC і формою відповіді можна зберегти під час розгортання.

Яку проблему він вирішує

Сьогодні найпростіша модель RPC зазвичай являє собою все або нічого: один ключ авторизації, один домен повноважень, повний доступ. Це працює для одного оператора, але не для загальнодоступної служби для кількох користувачів.

Загальнодоступний RPC без дозволу потребує потужнішої моделі:

• один сервіс може приймати багато користувачів
• кожен користувач отримує власні спільноти та обмеження
• політики, визначені оператором, можуть запобігти зловживанням
• користувач все ще може переїхати або самостійно розмістити пізніше

Основна модель

Користувачі

Кожен користувач отримує облікові дані для автентифікації та набір дозволів.

Спільноти

Спільноти, створені за допомогою служби, призначаються до запису власника. Право власності відстежується явно, щоб методи керування могли бути призначені для потрібного користувача.

Дозволи

Дозволи залежать від можливостей. Замість одного логічного значення для «можна використовувати RPC» сервер може контролювати:

• скільки спільнот може створити користувач
• які методи управління доступні
• які операції публікації дозволені
• які обмеження ставок застосовуються
• які поверхні адміністратора видимі

Поверхня адміністратора

Загальнодоступний RPC повинен залишатися зосередженим на поведінці користувача RPC. Такі адміністративні завдання, як створення користувачів, передача прав власності та перевірка аудиту, належать до окремого API оператора та інформаційної панелі.

Позиція сумісності

У призначеній для користувача документації слід використовувати такі терміни Bitsocial, як спільнота та профіль.

На рівні зв’язку перше розгортання все ще може зберегти поточний транспорт JSON-RPC і форму корисного навантаження, де це корисно для сумісності. Іншими словами: документам більше не потрібно говорити, як старі плебітські документи, навіть якщо перехідний період зберігає за лаштунками деякі застарілі назви методів або форми запитів.

Пропонований пакет дозволів

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 підписки.

Рекомендована поверхня оператора

API адміністратора може залишатися нудним і відвертим:

• список користувачів
• перевірити одного користувача
• створювати або оновлювати користувачів
• видалити користувачів
• передати у власність громади
• перевірити журнали аудиту

Автентифікація для цього API оператора має бути повністю окремою від RPC-автентифікації кінцевого користувача.

Фази розгортання

Фаза 1

• створити публічну структуру проекту RPC
• додати записи користувачів і відстеження власності
• розділити або розширити поточний сервер RPC

Фаза 2

• реалізувати пакети дозволів
• застосовувати їх на рівні методу RPC
• повертати метадані дозволів під час підключення

3 фаза

• додати API оператора
• додати журнал аудиту
• додати автентифікацію адміністратора

Фаза 4

• відправити інформаційну панель адміністратора
• перевірити засоби контролю зловживань
• посилити обмеження швидкості та квоти зберігання

Відкриті питання

Спам із обліковими даними авторизації

Якщо створення автентифікації є дешевим, державним службам може знадобитися рівень виклику перед видачею облікових даних. Одним із можливих шляхів є повторне використання самої моделі виклику спільноти, щоб видача облікових даних успадкувала ту саму філософію протидії зловживанням, що й решта мережі.

Застаріле найменування

Деякі ранні реалізації все ще можуть надавати внутрішні імена застарілих методів для сумісності. Це слід розглядати як деталь міграції, а не як постійний загальнодоступний словник документів Bitsocial.

Резюме

Ця пропозиція насправді стосується одного: зробити публічну інфраструктуру RPC корисною, не роблячи її опікунської. Хороший загальнодоступний RPC Bitsocial має виглядати як додаткова допомога для роботи спільнот, а не як нова центральна платформа, яка повертає право власності через чорний хід.