Dielde subdomeinen, twa yngongen: wa sjocht hokker records?

Klinyk A en Klinyk B diele ien koadebasis, twa subdomeinen en in miks fan besikers fan it kantoar en fan in VPN. Nettwurkteams binne oanstriid om de twa yngongen apart te konfigurearjen, en dat is prima, salang’t de applikaasje dat net docht. De kontrôles hjirûnder hearre yn de applikaasje en moatte itselde gedrage, hokker doar it fersyk ek brûkte.

Earst: de hostnamme neamt allinnich in hierder

Los de frege hostnamme op tsjin in mapping dy’t de administrateur ûnderhâldt, en ferwerp alles ûnbekend. Brûk de falidearre hostwearde fan it ramtwurk ynstee fan de rau header, sadat in ferfalske Host gjin sykkaai ynfiere kin. In suksesfolle oerienkomst fertelt de koade hokker hierderkonfiguraasje en merkfoarmjouwing te laden. It seit neat oer de fraach oft de oanropper de gegevens fan dy hierder sjen mei. Hâld dy twadde fraach yn in aparte funksje mei in aparte ynfier.

In dielde helperfunksje dy’t sawol kontekst as tastimming út ien hostnamme-syktocht weromjout, is it begjin fan de bug.

Twadde: lidmaatskip komt út de sesje

Sykje de aktive lidmaatskippen fan de ferifiearre brûker op en fergelykje se mei de hierder út de earste kontrôle. In brûker dy’t by beide klinken heart, mei wikselje, mar de wiksel moat in eksplisite hanneling wêze dy’t yn ’e fersykkontekst fêstlein is, net in ôflieding út ’e URL. In brûker dy’t by ien klink heart en de oare freget, wurdt wegere, ek foar downloads en API-oproppen.

Test it negative gefal troch in recordidentifikaasje en in hierderparameter te bewurkjen. As ien fan beide feroarings gegevens weromjout, wurdt it berik út it fersyk lêzen ynstee fan út it ferifiearre lidmaatskip.

Cookie-berik en ienmalige oanmelding bepale wêr’t in akkount presintearre wurde kin. Se bepale net wat dat akkount lêze mei.

Tredde: it netwurk bewiist neat oer de persoan

In VPN-gateway ferifiearret in tunnel, en in iepenbiere list mei tastiene adressen ferifiearret in adresberik. Gjin fan beide identifisearret in persoan. NAT bringt in protte brûkers byinoar yn ien boarneadres, en in kantoarberik docht itselde foar elkenien yn it gebou. Behannelje beide as ferfiersfeiten en hâld autorisaasje yn ’e applikaasje, of yn in yntegraasje dy’t identiteit eksplisyt beweart en as sadanich beoardiele wurdt.

DNS is in tredde ferfiersfeit. In privee antwurd hat in privee rûte nedich, en in iepenbier frontend hat in stipe oarsprongpaad nedich. Gjin fan harren draacht in tastimming.

Ien sin om oan ’e muorre te hâlden: it netwurk beslút hoe’t in fersyk oankomt, en de applikaasje beslút wat it lêze mei.

Fjirde: rin de matriks op beide yngongen

Brûk kontrolearre akkounts om A by A, B by B, A by B, in ûnbekende hostnamme en in ferifiearre akkount sûnder lidmaatskippen te testen. De fjirde en de fyfde moatte sletten mislearje en nea standert nei in hierder weromfalle. Rin deselde matriks ek troch de VPN-yngong, mei ien sesjepot per akkount:

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

Feroarje dan in item yn ’e list mei tastiene adressen en rin op ’e nij. In resultaat dat beweecht, betsjut dat in netwurkkontrôle in autorisaasjebeslút nimt.

Werhelje de matriks nei elke feroaring yn it frontend, want in twadde koadepaad dat de kontrôle oerslacht is de meast foarkommende manier wêrop dizze grins erodearret. It ferwachte resultaat is saai: elke yngong jout deselde antwurden.