భాగస్వామ్య సబ్‌డొమైన్‌లు, రెండు ప్రవేశ ద్వారాలు: ఎవరు ఏ రికార్డులను చూస్తారు?

క్లినిక్ 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

తర్వాత అనుమతి జాబితాలోని ఒక ఎంట్రీని మార్చి మళ్లీ నడపండి. కదిలే ఫలితం అంటే నెట్‌వర్క్ నియంత్రణ అనుమతి నిర్ణయం తీసుకుంటోంది.

ఫ్రంట్‌ఎండ్‌లో ఏదైనా మార్పు తర్వాత మ్యాట్రిక్స్‌ను పునరావృతం చేయండి, ఎందుకంటే తనిఖీని దాటవేసే రెండవ కోడ్ మార్గమే ఈ సరిహద్దు క్షీణించే అత్యంత సాధారణ మార్గం. ఆశించిన ఫలితం బోరింగ్: ప్రతి ప్రవేశ ద్వారం అదే సమాధానాలను ఇస్తుంది.