साझा सबडोमेन, दुई प्रवेशद्वार: कसले कुन रेकर्ड देख्छ?

क्लिनिक A र क्लिनिक B ले एउटै कोडबेस, दुई सबडोमेन र अफिस तथा VPN बाट आउने आगन्तुकहरूको मिश्रण साझा गर्छन्। नेटवर्क टोलीहरू सामान्यतया दुई प्रवेशद्वार अलग-अलग कन्फिगर गर्छन्, र त्यो ठीकै छ, जबसम्म एप्लिकेसनले त्यसो गर्दैन। तलका जाँचहरू एप्लिकेसनमै हुनुपर्छ र अनुरोध कुन ढोकाबाट आयो भन्ने कुराबाट स्वतन्त्र भई एउटै व्यवहार गर्नुपर्छ।

पहिलो: होस्टनामले एउटा टेनान्टको मात्र नाम बताउँछ

अनुरोध गरिएको होस्टनामलाई प्रशासकले राख्ने म्यापिङसँग मिलाएर हेर्नुहोस् र अज्ञात सबै कुरा अस्वीकार गर्नुहोस्। कच्चा हेडरको साटो फ्रेमवर्कको प्रमाणित होस्ट मान प्रयोग गर्नुहोस्, ताकि बनाइएको Host ले लुकअप कुञ्जी इन्जेक्ट गर्न नसकोस्। सफल मिलानले कोडलाई कुन टेनान्ट कन्फिगरेसन र कुन ब्रान्डिङ लोड गर्ने भनी बताउँछ। तर कल गर्नेले त्यो टेनान्टको डेटा देख्न सक्छ कि सक्दैन भन्ने कुरा यसले बताउँदैन। त्यो दोस्रो प्रश्न अलग इनपुट भएको अलग फंक्शनमा राख्नुहोस्।

एउटै होस्टनाम खोजबाट सन्दर्भ र अनुमति दुवै फर्काउने साझा सहायक फंक्शन बगको सुरुवात हो।

दोस्रो: सदस्यता सत्रबाट आउँछ

प्रमाणित प्रयोगकर्ताका सक्रिय सदस्यताहरू खोज्नुहोस् र तिनलाई पहिलो जाँचको टेनान्टसँग तुलना गर्नुहोस्। दुवै क्लिनिकमा पर्ने प्रयोगकर्ताले परिवर्तन गर्न सक्छ, तर त्यो परिवर्तन URL बाट निकालिएको अनुमान नभई अनुरोधको सन्दर्भमा अभिलेख गरिएको स्पष्ट कार्य हुनुपर्छ। एउटा क्लिनिकमा पर्ने प्रयोगकर्ताले अर्को माग्दा अस्वीकार गरिन्छ, डाउनलोड र API कलहरू सहित।

रेकर्ड पहिचानकर्ता र टेनान्ट प्यारामिटर सम्पादन गरेर नकारात्मक अवस्था जाँच्नुहोस्। दुईमध्ये कुनै परिवर्तनले डेटा फर्काएमा दायरा प्रमाणित सदस्यताबाट नभई अनुरोधबाट पढिएको हुन्छ।

कुकी दायरा र एकल साइन-अनले खाता कहाँ प्रस्तुत गर्न सकिन्छ भन्ने निर्धारण गर्छ। तीले त्यो खाताले के पढ्न सक्छ भन्ने निर्धारण गर्दैनन्।

तेस्रो: नेटवर्कले व्यक्तिको बारेमा केही पनि प्रमाणित गर्दैन

VPN गेटवेले सुरुङ प्रमाणित गर्छ, र सार्वजनिक अनुमति-सूचीले ठेगाना दायरा प्रमाणित गर्छ। कुनैले पनि व्यक्ति पहिचान गर्दैन। NAT ले धेरै प्रयोगकर्तालाई एउटै स्रोत ठेगानामा समेट्छ, र अफिस दायराले भवनका सबैका लागि त्यही गर्छ। दुवैलाई यातायात-तथ्य मान्नुहोस् र अनुमति एप्लिकेसनमै राख्नुहोस्, वा पहिचान स्पष्ट रूपमा घोषणा गर्ने र त्यही अनुसार समीक्षा हुने एकीकरणमा राख्नुहोस्।

DNS तेस्रो यातायात-तथ्य हो। निजी उत्तरका लागि निजी मार्ग चाहिन्छ, र सार्वजनिक फ्रन्टएन्डका लागि समर्थित मूल-मार्ग चाहिन्छ। तीमध्ये कुनैले पनि अनुमति बोक्दैन।

भित्तामा टाँस्न एक वाक्य: नेटवर्कले अनुरोध कसरी आउँछ भन्ने र एप्लिकेसनले के पढ्न सकिन्छ भन्ने निर्धारण गर्छ।

चौथो: दुवै प्रवेशद्वारमा म्याट्रिक्स चलाउनुहोस्

नियन्त्रित खाताहरू प्रयोग गरेर A लाई A मा, B लाई B मा, A लाई B मा, अज्ञात होस्टनाम र सदस्यता नभएको प्रमाणित खाता जाँच्नुहोस्। चौथो र पाँचौं बन्द रूपमा असफल हुनुपर्छ र कहिल्यै पूर्वनिर्धारित टेनान्टमा खस्नु हुँदैन। उही म्याट्रिक्स VPN प्रवेशद्वारबाट पनि चलाउनुहोस्, प्रत्येक खाताका लागि एउटा सत्र-जार लिएर:

curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-b.example.com/records/42
curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-a.example.com/records/42

त्यसपछि अनुमति-सूचीको एउटा प्रविष्टि परिवर्तन गरेर फेरि चलाउनुहोस्। सर्ने नतिजाको अर्थ नेटवर्क नियन्त्रणले अनुमतिको निर्णय गर्दै छ।

फ्रन्टएन्डमा कुनै पनि परिवर्तनपछि म्याट्रिक्स दोहोर्याउनुहोस्, किनकि जाँच छोड्ने दोस्रो कोड-मार्ग नै यो सीमा क्षय हुने सबैभन्दा सामान्य तरिका हो। अपेक्षित नतिजा निरस छ: हरेक प्रवेशद्वारले उही उत्तर दिन्छ।