Kunhavataj subdomajnoj, du enirejoj: kiu vidas kiujn rikordojn?

Kliniko A kaj Kliniko B kunhavas unu kodaron, du subdomajnojn kaj miksaĵon de vizitantoj el la oficejo kaj per VPN. Retaj teamoj emas agordi la du enirejojn aparte, kaj tio estas bone, kondiĉe ke la aplikaĵo ne faras tion. La kontroloj sube apartenas al la aplikaĵo kaj devus konduti idente sendepende de tio, kiun pordon la peto uzis.

Unue: la gastigantnomo nomas nur luanton

Solvu la petitan gastigantnomon kontraŭ mapado, kiun prizorgas la administranto, kaj malakceptu ĉion nekonatan. Uzu la validigitan gastigantvaloron de la kadro anstataŭ la kruda kaplinio, por ke falsita Host ne povu enŝovi serĉoklavon. Sukcesa kongruo diras al la kodo, kiun luantan agordon kaj kiun markadon ŝargi. Ĝi diras nenion pri tio, ĉu la alvokanto rajtas vidi la datumojn de tiu luanto. Tenu tiun duan demandon en aparta funkcio kun aparta enigo.

Komuna helposervo, kiu resendas kaj la kuntekston kaj la permeson el unu sola gastigantnoma serĉo, estas la komenco de la cimo.

Due: la membreco venas el la sesio

Serĉu la aktivajn membrecojn de la aŭtentigita uzanto kaj komparu ilin kun la luanto el la unua kontrolo. Uzanto, kiu apartenas al ambaŭ klinikoj, rajtas ŝanĝi, sed la ŝanĝo devus esti eksplicita ago registrita en la peta kunteksto, ne dedukto el la URL. Uzanto, kiu apartenas al unu kliniko kaj petas la alian, estas rifuzata, ankaŭ por elŝutoj kaj API-alvokoj.

Testu la negativan kazon per redakto de rikorda identigilo kaj luanta parametro. Se iu ajn el la du ŝanĝoj resendas datumojn, la amplekso estas legata el la peto anstataŭ el la kontrolita membreco.

La amplekso de kuketoj kaj unuopa ensaluto decidas, kie konto povas esti prezentata. Ili ne decidas, kion tiu konto rajtas legi.

Trie: la reto pruvas nenion pri la persono

VPN-enirejo aŭtentigas tunelon, kaj publika allaslisto aŭtentigas adresaron. Neniu el ili identigas personon. NAT kunpremas multajn uzantojn en unu fontadreson, kaj ofica adresaro faras la samon por ĉiuj en la konstruaĵo. Traktu ambaŭ kiel transportajn faktojn kaj tenu la rajtigon en la aplikaĵo, aŭ en integraĵo, kiu eksplicite asertas identecon kaj estas reviziata kiel tia.

DNS estas tria transporta fakto. Privata respondo bezonas privatan itineron, kaj publika fronto bezonas subtenatan originan vojon. Neniu el ili portas permeson.

Unu frazo por la muro: la reto decidas, kiel peto alvenas, kaj la aplikaĵo decidas, kion ĝi rajtas legi.

Kvare: rulu la matricon ĉe ambaŭ enirejoj

Uzu kontrolitajn kontojn por elprovi A ĉe A, B ĉe B, A ĉe B, nekonatan gastigantnomon kaj aŭtentigitan konton sen membrecoj. La kvara kaj la kvina devus malsukcesi fermite kaj neniam fali al luanto defaŭlte. Rulu la saman matricon ankaŭ tra la VPN-enirejo, kun unu sesia kruĉo por ĉiu 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/42

Poste ŝanĝu eron en la allaslisto kaj rulu denove. Rezulto, kiu moviĝas, signifas, ke reta kontrolo faras rajtigan decidon.

Ripetu la matricon post ĉiu antaŭa ŝanĝo, ĉar dua koda vojo, kiu preterpasas la kontrolon, estas la plej ofta maniero, kiel ĉi tiu limo erozias. La atendata rezulto estas enuiga: ĉiu enirejo produktas la samajn respondojn.