सामायिक सबडोमेन, दोन प्रवेशद्वारे: कोण कोणत्या नोंदी पाहतो?

क्लिनिक 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

नंतर परवानगी यादीतील एक नोंद बदला आणि पुन्हा चालवा। हलणारा निकाल म्हणजे नेटवर्क नियंत्रण अधिकृततेचा निर्णय घेत आहे।

फ्रंटएंडमधील कोणत्याही बदलानंतर मॅट्रिक्स पुन्हा चालवा, कारण तपासणी वगळणारा दुसरा कोड-मार्ग ही या सीमेची झीज होण्याची सर्वात सामान्य पद्धत आहे। अपेक्षित निकाल कंटाळवाणा आहे: प्रत्येक प्रवेशद्वार तीच उत्तरे देतो।