பகிரப்பட்ட துணை டொமைன்கள், இரண்டு நுழைவாயில்கள்: யார் எந்தப் பதிவுகளைப் பார்க்கிறார்?

கிளினிக் 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

பின்னர் அனுமதிப் பட்டியலில் ஒரு உள்ளீட்டை மாற்றி மீண்டும் இயக்குங்கள். நகரும் முடிவு என்பது ஒரு பிணையக் கட்டுப்பாடு அனுமதி முடிவெடுக்கிறது என்பதாகும்.

முன்முனையில் எந்த மாற்றத்திற்கும் பிறகு மேட்ரிக்ஸை மீண்டும் இயக்குங்கள், ஏனெனில் சரிபார்ப்பைத் தவிர்க்கும் இரண்டாவது குறியீட்டுப் பாதையே இந்த எல்லை அரிக்கப்படும் மிகவும் பொதுவான வழி. எதிர்பார்க்கப்பட்ட முடிவு சலிப்பானது: ஒவ்வொரு நுழைவாயிலும் அதே பதில்களைத் தருகிறது.