പങ്കിട്ട സബ്‌ഡൊമെയ്‌നുകൾ, രണ്ട് പ്രവേശന കവാടങ്ങൾ: ആരാണ് ഏത് രേഖകൾ കാണുന്നത്?

ക്ലിനിക് 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

പിന്നീട് അനുമതി പട്ടികയിലെ ഒരു എൻട്രി മാറ്റി വീണ്ടും പ്രവർത്തിപ്പിക്കുക. നീങ്ങുന്ന ഫലം എന്നാൽ ഒരു നെറ്റ്‌വർക്ക് നിയന്ത്രണം അനുമതി തീരുമാനം എടുക്കുന്നു എന്നാണ്.

ഫ്രണ്ട്‌എൻഡിലെ ഏത് മാറ്റത്തിനും ശേഷം മാട്രിക്സ് ആവർത്തിക്കുക, കാരണം പരിശോധന ഒഴിവാക്കുന്ന രണ്ടാമത്തെ കോഡ് പാതയാണ് ഈ അതിർത്തി ക്ഷയിക്കുന്ന ഏറ്റവും സാധാരണ വഴി. പ്രതീക്ഷിക്കുന്ന ഫലം വിരസമാണ്: ഓരോ കവാടവും ഒരേ ഉത്തരങ്ങൾ നൽകുന്നു.