การผสานรวมแบบ Multi-Tenancy
Ultimate Multisite: Multi-Tenancy 1.2.0 เปลี่ยนจุดเชื่อมต่อการผสานรวมหลายส่วนสำหรับ tenant แบบอธิปไตย การตรวจสอบการย้ายข้อมูล และการทำงานอัตโนมัติของวงจรชีวิต tenant
โฟลว์การเริ่มต้น tenant
การผสานรวมที่สร้างหรือแก้ไข tenant ควรทำตามลำดับนี้:
- ระเบียนรีจิสทรี tenant และโมเดลการแยกสภาพแวดล้อม
- สร้างหรือตรวจสอบตัวเขียนฐานข้อมูลของ tenant
- เริ่มต้นสคีมาของ tenant
- จัดเตรียมผู้ใช้ของ tenant
- ลงทะเบียนการกำหนดเส้นทางและพาธระบบไฟล์ของ tenant
- เรียกใช้การตรวจสอบการย้ายข้อมูลก่อนเปิดให้เข้าถึง tenant
อย่าสันนิษฐานว่า tenant แบบอธิปไตยสามารถใช้การเชื่อมต่อฐานข้อมูลเครือข่ายซ้ำได้ ใช้รีจิสทรี tenant และ abstraction ของตัวเขียนที่ addon จัดเตรียมไว้
SSO และ REST hooks
การเข้าสู่ระบบอัตโนมัติของ tenant แบบไร้สถานะใช้ token อายุสั้นพร้อม purpose claim, การป้องกันการเล่นซ้ำ JTI, ขีดจำกัดวันหมดอายุ และการตรึง origin การผสานรวมที่เพิ่มปุ่มเข้าสู่ระบบหรือลิงก์การจัดการระยะไกลควรสร้างการเยี่ยมชม tenant ผ่านโฟลว์ SSO ที่รองรับ แทนที่จะสร้าง URL เข้าสู่ระบบของ tenant โดยตรง
เหตุการณ์ audit ของ API ฝั่งเครือข่ายและสรุปรายวันพร้อมใช้งานสำหรับ gateway ของ tenant แบบอธิปไตย ใช้บันทึกเหล่านั้นเมื่อดีบักระบบภายนอกที่เรียก endpoint วงจรชีวิต tenant
URL การดำเนินการของลูกค้าแบบอธิปไตย
Ultimate Multisite v2.13.0 กำหนดเส้นทางการดำเนินการของลูกค้า tenant แบบอธิปไตยกลับไปยัง site หลักสำหรับโฟลว์ account, checkout, billing, invoice, site, การสลับ template และ domain-mapping การผสานรวมที่แสดงลิงก์การจัดการฝั่ง tenant ควรชี้การดำเนินการเหล่านั้นไปที่ panel ลูกค้าใน site หลัก และรวมเป้าหมายการกลับที่ผ่านการตรวจสอบแล้วเมื่อผู้ใช้ควรสามารถนำทางกลับไปยัง tenant หลังจากทำการดำเนินการเสร็จ
ใช้ wrapper SSO หลักสำหรับลิงก์การจัดการข้ามโดเมน:
$url = wu_with_sso($main_site_customer_url);
URL ที่สร้างยังคงสามารถกรองได้ผ่าน wu_sso_url ซึ่งรับ URL SSO, ผู้ใช้ปัจจุบัน, ID site เป้าหมาย และบริบท redirect Add-ons สามารถใช้ filter นั้นเพื่อผนวกบริบทเฉพาะ provider หรือแทนที่ broker URL โดยยังคงรักษาการตรวจสอบ token ของ Ultimate Multisite ไว้
อย่าทำซ้ำสถานะ membership, invoice, billing-address, template หรือ domain-management ภายใน tenant แบบอธิปไตย ให้ถือว่า Dashboard ของ tenant เป็นตัวเรียกใช้งาน และ panel ลูกค้าใน site หลักเป็นแหล่งข้อมูลหลักของระบบสำหรับการดำเนินการที่มีการจัดการ
การตรวจสอบการย้ายข้อมูล
หลังจากการย้ายข้อมูลหรือการผสานรวมวงจรชีวิตเปลี่ยนข้อมูล tenant ให้เรียกใช้ด่านตรวจสอบ:
wp tenant verify-no-legacy --site=<site-id>ยืนยันว่า tenant ไม่พึ่งพาพาธฝั่งเครือข่ายแบบเดิมอีกต่อไ ปwp tenant verify-sovereign-push --site=<site-id>ยืนยันว่า job push แบบอธิปไตยสามารถประมวลผลและระบายคิวได้
การผสานรวมควรถือว่าการตรวจสอบที่ล้มเหลวเป็นตัวบล็อกการ deploy และหลีกเลี่ยงการทำเครื่องหมายว่า tenant live จนกว่าความล้มเหลวจะได้รับการแก้ไข
การลบ tenant
โฟลว์การลบควรเรียกพาธ teardown ของ addon เพื่อให้ข้อมูลรับรองฐานข้อมูลของ tenant ถูกล้างออก การผสานรวมภายนอกอาจลบทรัพยากรของ provider หลังจาก teardown สำเร็จ แต่ไม่ควรลบฐานข้อมูลหรือโฟลเดอร์บน host ขณะที่การตรวจสอบหรือ job push แบบ async ยังทำงานอยู่
ตัวกำหนดเส้นทางฐานข้อมูลที่เลิกใช้แล้ว
Database_Router แบบเดิมถูกแทนที่ด้วย stub การเลิกใช้แล้ว การผสานรวมใหม่ควร resolve tenant ผ่าน API ของ site router และรีจิสทรี tenant ปัจจุบัน แทนที่จะพึ่งพาคลาส router เก่า