Partekatutako azpidomeinuak, bi sarrera: nork ikusten ditu zein erregistro?

A klinikak eta B klinikak kode-base bat, bi azpidomeinu eta bulegoko eta VPN bidezko bisitarien nahasketa partekatzen dituzte. Sare-taldeek bi sarrerak bereiz konfiguratzeko joera dute, eta hori ondo dago, aplikazioak ez duen bitartean. Beheko egiaztapenak aplikazioarenak dira eta berdin jokatu behar dute eskaerak zein ate erabili duen ere.

Lehenengo: ostalari-izenak errentari bat baino ez du izendatzen

Ebatzi eskatutako ostalari-izena administratzaileak mantentzen duen mapatzearen aurka, eta baztertu ezezaguna den oro. Erabili framework-aren ostalari-balio baliozkotua goiburu gordina ordez, faltsututako Host batek bilaketa-gako bat injekta ez dezan. Bat-etortze arrakastatsuak kodeari esaten dio zein errentari-konfigurazio eta marka kargatu. Ez du ezer esaten deitzaileak errentari horren datuak ikus ditzakeen ala ez. Eutsi bigarren galdera horri sarrera bereizia duen funtzio bereizi batean.

Ostalari-izenaren bilaketa bakar batetik bai testuingurua bai baimena itzultzen dituen laguntza-funtzio partekatua akatsaren hasiera da.

Bigarren: kidetza saiotik dator

Bilatu autentifikatutako erabiltzailearen kidetza aktiboak eta alderatu lehen egiaztapeneko errentariarekin. Bi kliniketakoa den erabiltzaileak alda dezake, baina aldaketak eskaeraren testuinguruan erregistratutako ekintza esplizitua izan behar du, ez URLtik ateratako inferentzia. Klinika batekoa den eta bestea eskatzen duen erabiltzaileari ukatu egiten zaio, deskargak eta API deiak barne.

Probatu kasu negatiboa erregistro-identifikatzaile bat eta errentari-parametro bat aldatuta. Aldaketa bietatik edozeinek datuak itzuliz gero, esparrua eskaeratik irakurtzen da, ez egiaztatutako kidetzatik.

Cookieen esparruak eta saio-hasiera bakarrak erabakitzen dute non aurkez daitekeen kontu bat. Ez dute erabakitzen kontu horrek zer irakur dezakeen.

Hirugarren: sareak ezer ez du frogatzen pertsonari buruz

VPN atebide batek tunel bat autentifikatzen du, eta baimendutako zerrenda publiko batek helbide-tarte bat autentifikatzen du. Bietako batek ere ez du pertsona bat identifikatzen. NATek erabiltzaile asko iturburu-helbide bakarrean biltzen ditu, eta bulego-tarte batek eraikineko guztiekin gauza bera egiten du. Hartu biak garraio-egitate gisa eta eutsi baimen-ematea aplikazioan, edo identitatea esplizituki baieztatzen duen eta hala berrikusten den integrazio batean.

DNS hirugarren garraio-egitatea da. Erantzun pribatuak ibilbide pribatua behar du, eta aurrealde publikoak jatorri-bide onartua behar du. Horietako batek ere ez du baimenik darama.

Hormaren kontra jartzeko esaldi bat: sareak erabakitzen du eskaera nola iristen den, eta aplikazioak erabakitzen du zer irakur dezakeen.

Laugarren: exekutatu matrizea bi sarreretan

Erabili kontu kontrolatuak A A-n, B B-n, A B-n, ostalari-izen ezezagun bat eta kidetzarik gabeko kontu autentifikatu bat probatzeko. Laugarrenak eta bosgarrenak itxita huts egin behar dute, eta inoiz ez dute lehenetsitako errentari batera jo behar. Exekutatu matrize bera VPN sarreraren bidez ere, kontu bakoitzeko saio-pote bat:

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

Gero aldatu baimendutako zerrendako sarrera bat eta exekutatu berriro. Mugitzen den emaitza batek sare-kontrol batek baimen-erabakia hartzen duela esan nahi du.

Errepikatu matrizea aurrealdeko edozein aldaketaren ondoren, egiaztapena saltatzen duen bigarren kode-bidea delako muga hau higatzeko modurik ohikoena. Espero den emaitza aspergarria da: sarrera bakoitzak erantzun berdinak sortzen ditu.