मल्टी-टेनेंसी एकीकरण
Ultimate Multisite: मल्टी-टेनेंसी 1.2.0 संप्रभु टेनेंट, माइग्रे शन सत्यापन, और टेनेंट जीवनचक्र स्वचालन के लिए कई एकीकरण संपर्क बिंदु बदलता है।
टेनेंट आरंभीकरण प्रवाह
जो एकीकरण टेनेंट बनाते या संशोधित करते हैं, उन्हें यह क्रम अपनाना चाहिए:
- टेनेंट रजिस्ट्री रिकॉर्ड और आइसोलेशन मॉडल निर्धारित करें।
- टेनेंट डेटाबेस राइटर बनाएँ या सत्यापित करें।
- टेनेंट स्कीमा आरंभ करें।
- टेनेंट उपयोगकर्ताओं का प्रावधान करें।
- टेनेंट रूटिंग और फाइल सिस्टम पथ पंजीकृत करें।
- टेनेंट को उपलब्ध कराने से पहले माइग्रेशन सत्यापन चलाएँ।
यह न मानें कि कोई संप्रभु टेनेंट नेटवर्क डेटाबेस कनेक्शन का फिर से उपयोग कर सकता है। ऐडऑन द्वारा दिए गए टेनेंट रजिस्ट्री और राइटर एब्स्ट्रैक्शन का उपयोग करें।
SSO और REST हुक्स
स्टेटलेस टेनेंट ऑटोलॉगिन छोटे समय तक मान्य टोकन का उपयोग करता है, जिनमें उद्देश्य दावा, JTI रीप्ले सुरक्षा, समाप्ति सीमा, और मूल पिनिंग होती है। जो एकीकरण लॉगिन बटन या दूरस्थ प्रबंधन लिंक जोड़ते हैं, उन्हें सीधे टेनेंट लॉगिन URL बनाने के बजाय समर्थित SSO प्रवाह से टेनेंट विज़िट बनानी चाहिए।
नेटवर्क-साइड API ऑडिट इवेंट और दैनिक सारांश संप्रभु टेनेंट गेटवे के लिए उपलब्ध हैं। टेनेंट जीवनचक्र एंडपॉइंट कॉल करने वाले बाहरी सिस्टम डीबग करते समय इन लॉग का उपयोग करें।
संप्रभु ग्राहक कार्रवाई URL
Ultimate Multisite v2.13.0 संप्रभु-टेनेंट ग्राहक कार्रवाइयों को Account, चेकआउट, बिलिंग, चालान, साइट, टेम्पलेट-स्विचिंग, और डोमेन-मैपिंग प्रवाहों के लिए मुख्य साइट पर वापस रूट करता है। जो एकीकरण टेनेंट-साइड प्रबंधन लिंक दिखाते हैं, उन्हें इन कार्रवाइयों को मुख्य-साइट ग्राहक पैनल की ओर इंगित करना चाहिए और जब उपयोगकर्ता कार्रवाई पूरी करने के बाद टेनेंट पर वापस जा सके, तब एक सत्यापित वापसी लक्ष्य शामिल करना चाहिए।
क्रॉस-डोमेन प्रबंधन लिंक के लिए कोर SSO रैपर का उपयोग करें:
$url = wu_with_sso($main_site_customer_url);
जनरेट किया गया URL wu_sso_url के माध्यम से फ़िल्टर किया जा सकता है, जिसे SSO URL, मौजूदा उपयोगकर्ता, लक्ष्य साइट ID, और रीडायरेक्ट संदर्भ प्राप्त होते हैं। ऐडऑन उस फ़िल्टर का उपयोग प्रदाता-विशिष्ट संदर्भ जोड़ने या Ultimate Multisite के टोकन सत्यापन को बनाए रखते हुए ब्रोकर URL बदलने के लिए कर सकते हैं।
संप्रभु टेनेंट के अंदर सदस्यता, चालान, बिलिंग-पता, टेम्पलेट, या डोमेन-प्रबंधन स्थिति की नकल न करें। टेनेंट Dashboard को लॉन्चर मानें और मुख्य-साइट ग्राहक पैनल को प्रबंधित कार्रवाइयों के लिए आधिकारिक सिस्टम मानें।
माइग्रेशन सत्यापन
माइग्रेशन या जीवनचक्र एकीकरण द्वारा टेनेंट डेटा बदलने के बाद, सत्यापन गेट चलाएँ:
wp tenant verify-no-legacy --site=<site-id>पुष्टि करता है कि टेनेंट अब पुराने नेटवर्क-साइड पथों पर निर्भर नहीं है।wp tenant verify-sovereign-push --site=<site-id>पुष्टि करता है कि संप्रभु पुश जॉब प्रोसेस होकर खाली हो सकते हैं।
एकीकरणों को असफल सत्यापन को परिनियोजन अवरोधक मानना चाहिए और विफलता ठीक होने तक टेनेंट को लाइव चिह्नित करने से बचना चाहिए।
टेनेंट हटाना
हटाने के प्रवाहों को ऐडऑन टीयरडाउन पथ कॉल करना चाहिए ताकि टेनेंट डेटाबेस क्रेडेंशियल साफ़ हो जाएँ। टीयरडाउन सफल होने के बाद बाहरी एकीकरण प्रदाता संसाधन हटा सकते हैं, लेकिन सत्यापन या एसिंक पुश जॉब अभी चल रहे हों, तो होस्ट डेटाबेस या फ़ोल्डर नहीं हटाने चाहिए।
अप्रचलित डेटाबेस राउटर
पुराने Database_Router को अप्रचलन स्टब से बदल दिया गया है। नए एकीकरणों को पुराने राउटर क्लास पर निर्भर रहने के बजाय मौजूदा साइट राउटर और टेनेंट रजिस्ट्री API के माध्यम से टेनेंट निर्धारित करने चाहिए।