Ортақ субдомендер, екі кіреберіс: кім қай жазбаларды көреді?

A клиникасы мен B клиникасы бір кодтық базаны, екі субдоменді және кеңседен келетін және VPN арқылы келетін келушілердің қоспасын бөліседі. Желі топтары әдетте екі кіреберісті бөлек баптайды, және бұл қалыпты, қолданба солай істемейінше. Төмендегі тексерулер қолданбада болуы керек және сұраныс қай есікті пайдаланғанына қарамастан бірдей әрекет етуі керек.

Бірінші: хост атауы тек жалдаушыны атайды

Сұралған хост атауын әкімші ұстайтын сәйкестендіру кестесі бойынша шешіп, барлық белгісізді қабылдамаңыз. Шикі тақырыптың орнына фреймворктің расталған хост мәнін пайдаланыңыз, сонда жасалма Host іздеу кілтін енгізе алмайды. Сәтті сәйкестік кодқа қай жалдаушы конфигурациясы мен қай брендингті жүктеу керегін айтады. Ол шақырушының сол жалдаушының деректерін көре алатыны туралы ештеңе айтпайды. Осы екінші сұрақты бөлек кірісі бар бөлек функцияда ұстаңыз.

Бір хост атауын іздеуден контекст пен рұқсатты бірге қайтаратын ортақ көмекші функция қателіктің басы.

Екінші: мүшелік сессиядан келеді

Аутентификацияланған пайдаланушының белсенді мүшеліктерін тауып, оларды бірінші тексерудің жалдаушысымен салыстырыңыз. Екі клиникаға да тиесілі пайдаланушы ауыса алады, бірақ ауысу URL-ден шығарылған қорытынды емес, сұраныс контекстінде тіркелген айқын әрекет болуы керек. Бір клиникаға тиесілі пайдаланушы екіншісін сұраса, оған бас тартылады, оның ішінде жүктеулер мен API шақырулары үшін де.

Теріс жағдайды жазба идентификаторын және жалдаушы параметрін өзгерту арқылы тексеріңіз. Екі өзгерістің қайсысы болса да деректер қайтарса, ауқым расталған мүшеліктен емес, сұраныстан оқылады.

Cookie ауқымы мен бір реттік кіру тіркелгіні қайда ұсынуға болатынын анықтайды. Олар сол тіркелгінің нені оқи алатынын анықтамайды.

Үшінші: желі адам туралы ештеңе дәлелдемейді

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

Содан кейін рұқсат тізіміндегі бір жазбаны өзгертіп, қайта іске қосыңыз. Жылжыған нәтиже желілік бақылау авторизация шешімін қабылдап жатқанын білдіреді.

Фронтендтегі кез келген өзгерістен кейін матрицаны қайталаңыз, өйткені тексеруді айналып өтетін екінші код жолы бұл шекараның эрозиясының ең көп тараған жолы. Күтілетін нәтиже зеріктіреді: әр кіреберіс бірдей жауаптар береді.