ข้ามไปที่เนื้อหาหลัก

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;
  };
};

ชื่อวิธีการที่แน่นอนเป็นเพียงตัวอย่างเท่านั้น ส่วนที่สำคัญคือรูปร่างของนโยบาย: ความสามารถส่วนบุคคลได้รับการควบคุมอย่างเป็นอิสระ แทนที่จะรวมเป็นโทเค็น superuser เดียว

การไหลของการเชื่อมต่อ​

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

การรับรู้สิทธิ์ควรเป็นตัวเลือก ไคลเอ็นต์ที่เพิกเฉยต่อการแจ้งเตือนยังคงสามารถทำงานได้อย่างถูกต้องโดยจัดการกับความล้มเหลวในการอนุญาตมาตรฐานจากเซิร์ฟเวอร์

การบังคับใช้ความเป็นเจ้าของ​

เมื่อบริการสร้างชุมชน ควรกำหนดความเป็นเจ้าของให้กับผู้ใช้ที่โทรโดยอัตโนมัติ จากนั้น:

  • การดำเนินการเริ่มต้น หยุด แก้ไข และลบของชุมชนมีการกำหนดขอบเขตโดยเจ้าของ
  • การตอบกลับรายการและการสมัครสมาชิกเป็นค่าเริ่มต้นสำหรับชุมชนของผู้โทร
  • การมองเห็นที่กว้างขึ้นคือการอนุญาตของผู้ดูแลระบบที่ชัดเจน ไม่ใช่ค่าเริ่มต้น

กรณี Edge หนึ่งกรณีมีความสำคัญมาก: หากผู้ใช้สมัครเป็นสมาชิกชุมชนที่พวกเขา ไม่ได้ เป็นเจ้าของ เซิร์ฟเวอร์จะต้องเปิดเผยเฉพาะสถานะสาธารณะที่ผู้สังเกตการณ์ภายนอกควรเห็นเท่านั้น ข้อมูลการกำหนดค่าหรือรันไทม์ภายในเฉพาะเจ้าของไม่ควรรั่วไหลผ่าน API การสมัครสมาชิก

พื้นผิวของผู้ปฏิบัติงานที่แนะนำ​

API ผู้ดูแลระบบสามารถทำให้น่าเบื่อและชัดเจน:

  • ผู้ใช้รายการ
  • ตรวจสอบผู้ใช้หนึ่งราย
  • สร้างหรืออัปเดตผู้ใช้
  • ลบผู้ใช้
  • โอนความเป็นเจ้าของชุมชน
  • ตรวจสอบบันทึกการตรวจสอบ

การตรวจสอบสิทธิ์สำหรับ API ตัวดำเนินการนี้ควรแยกจากการตรวจสอบสิทธิ์ RPC ของผู้ใช้ปลายทางโดยสิ้นเชิง

ระยะการเปิดตัว​

ระยะที่ 1​

  • กำหนดโครงสร้างโครงการ RPC สาธารณะ
  • เพิ่มบันทึกผู้ใช้และการติดตามความเป็นเจ้าของ
  • แยกหรือขยายเซิร์ฟเวอร์ RPC ปัจจุบัน

ระยะที่ 2​

  • ใช้ชุดสิทธิ์
  • บังคับใช้ที่เลเยอร์วิธี RPC
  • ส่งคืนข้อมูลเมตาการอนุญาตในการเชื่อมต่อ

ระยะที่ 3​

  • เพิ่มตัวดำเนินการ API
  • เพิ่มการบันทึกการตรวจสอบ
  • เพิ่มการรับรองความถูกต้องของผู้ดูแลระบบ

ระยะที่ 4​

  • จัดส่งแดชบอร์ดผู้ดูแลระบบ
  • ทดสอบการควบคุมการละเมิด
  • กระชับการจำกัดอัตราและโควต้าการจัดเก็บ

คำถามเปิด​

สแปมข้อมูลรับรองความถูกต้อง​

หากการสร้างการรับรองความถูกต้องมีราคาถูก บริการสาธารณะอาจต้องมีระดับความท้าทายก่อนที่จะออกข้อมูลรับรอง เส้นทางหนึ่งที่เป็นไปได้คือการนำโมเดลความท้าทายของชุมชนกลับมาใช้ใหม่ ดังนั้นการออกหนังสือรับรองจึงสืบทอดปรัชญาต่อต้านการละเมิดเช่นเดียวกับส่วนที่เหลือในเครือข่าย

การตั้งชื่อมรดก​

การใช้งานในช่วงแรกๆ บางอย่างอาจยังคงเปิดเผยชื่อวิธีการแบบเดิมเป็นการภายในเพื่อความเข้ากันได้ นั่นควรถือเป็นรายละเอียดการโยกย้าย ไม่ใช่เป็นคำศัพท์สาธารณะแบบถาวรของเอกสาร Bitsocial

สรุป​

ข้อเสนอนี้มีเรื่องเกี่ยวกับสิ่งหนึ่งจริงๆ นั่นคือการทำให้โครงสร้างพื้นฐาน RPC สาธารณะมีประโยชน์โดยไม่ต้องถูกควบคุม Bitsocial RPC สาธารณะที่ดีควรรู้สึกเหมือนเป็นความช่วยเหลือเพิ่มเติมสำหรับการดำเนินการชุมชน ไม่ใช่เหมือนแพลตฟอร์มกลางใหม่ที่เรียกคืนความเป็นเจ้าของผ่านประตูหลัง