Delte underdomæner, to indgange: hvem ser hvilke poster?
Et underdomæne vælger branding, og et verificeret medlemskab vælger data. Kør de samme lejerkontroller, uanset om en anmodning kommer fra en kontoradresse eller fra en VPN.
Klinik A og Klinik B deler én kodebase, to underdomæner og en blanding af besøgende fra kontoret og fra VPN. Netværksteams har en tendens til at konfigurere de to indgange hver for sig, og det er fint, så længe applikationen ikke gør det. Kontrollerne nedenfor hører hjemme i applikationen og bør opføre sig identisk, uanset hvilken dør anmodningen brugte.
Først: værtsnavnet navngiver kun en lejer
Slå det anmodede værtsnavn op i en mapping, som administratoren vedligeholder, og afvis alt ukendt. Brug frameworkets validerede værtværdi i stedet for den rå header, så en konstrueret Host ikke kan indsprøjte en opslagsnøgle. Et vellykket match fortæller koden, hvilken lejerkonfiguration og branding der skal indlæses. Det siger intet om, hvorvidt den kaldende må se den lejers data. Hold det andet spørgsmål i en separat funktion med et separat input.
En delt hjælpefunktion, der returnerer både kontekst og tilladelse fra et enkelt værtsnavnsopslag, er begyndelsen på fejlen.
Dernæst: medlemskab kommer fra sessionen
Slå den godkendte brugers aktive medlemskaber op, og sammenlign dem med lejeren fra den første kontrol. En bruger, der tilhører begge klinikker, må skifte, men skiftet bør være en eksplicit handling registreret i anmodningskonteksten, ikke en slutning fra URL’en. En bruger, der tilhører den ene klinik og anmoder om den anden, afvises, også for downloads og API-kald.
Test det negative tilfælde ved at redigere en postidentifikator og en lejerparameter. Hvis en af ændringerne returnerer data, læses omfanget fra anmodningen snarere end fra det verificerede medlemskab.
Cookie-omfang og enkeltlogon afgør, hvor en konto kan præsenteres. De afgør ikke, hvad den konto må læse.
For det tredje: netværket beviser intet om personen
En VPN-gateway godkender en tunnel, og en offentlig tilladelsesliste godkender et adresseområde. Ingen af dem identificerer en person. NAT samler mange brugere i én kildeadresse, og et kontorområde gør det samme for alle i bygningen. Behandl begge som transportfakta, og hold autorisationen i applikationen eller i en integration, der eksplicit erklærer identitet og gennemgås som sådan.
DNS er et tredje transportfaktum. Et privat svar kræver en privat rute, og en offentlig frontend kræver en understøttet oprindelsessti. Ingen af dem bærer en tilladelse.
En sætning til væggen: netværket afgør, hvordan en anmodning ankommer, og applikationen afgør, hvad den må læse.
For det fjerde: kør matricen på begge indgange
Brug kontrollerede konti til at afprøve A hos A, B hos B, A hos B, et ukendt værtsnavn og en godkendt konto uden medlemskaber. Den fjerde og den femte bør fejle lukket og aldrig falde tilbage til en lejer. Kør den samme matrix gennem VPN-indgangen også, med én sessionskrukke for hver konto:
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/42Skift derefter en post i tilladelseslisten, og kør igen. Et resultat, der flytter sig, betyder, at en netværkskontrol træffer en autorisationsbeslutning.
Gentag matricen efter enhver ændring i frontend, fordi en anden kodesti, der springer kontrollen over, er den mest almindelige måde, denne grænse eroderer på. Det forventede resultat er kedeligt: hver indgang giver de samme svar.