Subdomain zinazoshirikiwa, milango miwili: nani anaona rekodi zipi?

Kliniki A na Kliniki B hushiriki msingi mmoja wa msimbo, subdomain mbili na mchanganyiko wa wageni kutoka ofisini na kwa VPN. Timu za mtandao huwa na tabia ya kusanidi milango miwili kando, na hilo ni sawa, mradi programu haifanyi hivyo. Ukaguzi ulio hapa chini unapaswa kuwa ndani ya programu na kufanya kwa namna moja bila kujali mlango gani ombi lilitumia.

Kwanza: jina la mwenyeji linamtaja mpangaji tu

Tatua jina la mwenyeji lililoombwa dhidi ya ramani inayotunzwa na msimamizi, na kataa kitu chochote kisichojulikana. Tumia thamani ya mwenyeji iliyothibitishwa na mfumo badala ya kichwa ghafi, ili Host iliyotengenezwa isiweze kuingiza ufunguo wa utafutaji. Ulinganisho wenye mafanikio huambia msimbo ni usanidi gani wa mpangaji na chapa ipi ipakiwe. Lakini haisemi kama mpigaji anaweza kuona data ya mpangaji huyo. Weka swali hilo la pili katika kitendakazi tofauti na ingizo tofauti.

Kitendakazi kisaidizi kinachoshirikiwa kinachorudisha muktadha na ruhusa kutoka kwa utafutaji mmoja wa jina la mwenyeji ni mwanzo wa hitilafu.

Pili: uanachama unatoka kwenye kikao

Tafuta uanachama hai wa mtumiaji aliyethibitishwa na ulinganishe na mpangaji wa ukaguzi wa kwanza. Mtumiaji aliye katika kliniki zote mbili anaweza kubadilisha, lakini mabadiliko hayo yanapaswa kuwa kitendo dhahiri kilichorekodiwa katika muktadha wa ombi, si hitimisho kutoka kwa URL. Mtumiaji aliye katika kliniki moja na kuomba nyingine anakataliwa, ikiwa ni pamoja na upakuaji na simu za API.

Jaribu hali hasi kwa kuhariri kitambulisho cha rekodi na kigezo cha mpangaji. Ikiwa mojawapo ya mabadiliko inarudisha data, wigo unasomwa kutoka kwa ombi badala ya uanachama uliothibitishwa.

Wigo wa vidakuzi na kuingia kwa mara moja huamua akaunti inaweza kuwasilishwa wapi. Hayaamui kile akaunti hiyo inaweza kusoma.

Tatu: mtandao hauthibitishi chochote kuhusu mtu

Lango la VPN huthibitisha handaki, na orodha ya ruhusa ya umma huthibitisha wigo wa anwani. Hakuna hata moja inayomtambua mtu. NAT hukusanya watumiaji wengi katika anwani moja ya chanzo, na wigo wa ofisi hufanya vivyo hivyo kwa kila mtu ndani ya jengo. Chukua zote mbili kama ukweli wa usafirishaji na uweke idhini ndani ya programu, au katika muunganisho unaodai utambulisho kwa uwazi na kukaguliwa kwa namna hiyo.

DNS ni ukweli wa tatu wa usafirishaji. Jibu la faragha linahitaji njia ya faragha, na sehemu ya mbele ya umma inahitaji njia ya asili inayotumika. Hakuna hata moja inayobeba ruhusa.

Sentensi moja ya kuweka ukutani: mtandao huamua jinsi ombi linafika, na programu huamua kile inaweza kusoma.

Nne: endesha matrix kwenye milango yote miwili

Tumia akaunti zinazodhibitiwa kujaribu A kwa A, B kwa B, A kwa B, jina la mwenyeji lisilojulikana na akaunti iliyothibitishwa isiyo na uanachama. Ya nne na ya tano yanapaswa kushindwa kwa kufungwa na kamwe yasishuke kwa mpangaji chaguo-msingi. Endesha matrix hiyo hiyo kupitia lango la VPN pia, ukiwa na jar moja ya kikao kwa kila akaunti:

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

Kisha badilisha kipengee kimoja cha orodha ya ruhusa na uendeshe tena. Matokeo yanayosogea yanamaanisha udhibiti wa mtandao unafanya uamuzi wa idhini.

Rudia matrix baada ya kila mabadiliko ya sehemu ya mbele, kwa sababu njia ya pili ya msimbo inayoruka ukaguzi ndiyo njia ya kawaida zaidi ambayo mpaka huu huoza. Matokeo yanayotarajiwa ni ya kuchosha: kila lango hutoa majibu sawa.