Споделени поддомени, два влеза: кој кои записи ги гледа?

Клиника 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

Потоа сменете еден запис на списокот за дозвола и пуштете повторно. Резултат што се поместува значи дека мрежна контрола носи одлука за авторизација.

Повторете ја матрицата по секоја промена на фронтендот, зашто вториот коден пат што ја прескокнува проверката е најчестиот начин на кој оваа граница еродира. Очекуваниот резултат е здодевен: секој влез дава исти одговори.