Համօգտագործվող ենթադոմեյններ, երկու մուտք. ո՞վ է տեսնում որ գրառումները։

Կլինիկա A-ն և Կլինիկա B-ն կիսում են մեկ կոդային բազա, երկու ենթադոմեյն և գրասենյակից ու VPN-ից եկող այցելուների խառնուրդ։ Ցանցային թիմերը սովորաբար երկու մուտքերը կարգավորում են առանձին, և դա նորմալ է, քանի դեռ հավելվածը այդպես չի անում։ Ստորև բերված ստուգումները պետք է լինեն հավելվածում և վարվեն նույն կերպ՝ անկախ այն բանից, թե որ դռնով է եկել հարցումը։

Առաջին՝ հոսթի անունը միայն վարձակալի է անվանում

Լուծեք պահանջվող հոսթի անունը ըստ ադմինիստրատորի պահպանած քարտեզագրման և մերժեք ամեն անհայտը։ Օգտագործեք ֆրեյմվորկի վավերացված հոսթի արժեքը՝ հում վերնագրի փոխարեն, որպեսզի կեղծված Host-ը չկարողանա որոնման բանալի ներարկել։ Հաջող համընկնումը կոդին ասում է, թե որ վարձակալի կոնֆիգուրացիան և որ բրենդինգը բեռնել։ Այն ոչինչ չի ասում այն մասին, թե արդյոք զանգահարողը կարող է տեսնել այդ վարձակալի տվյալները։ Երկրորդ հարցը պահեք առանձին ֆունկցիայում՝ առանձին մուտքով։

Մեկ հոսթի անվան որոնումից և՛ համատեքստը, և՛ թույլտվությունը վերադարձնող ընդհանուր օժանդակ ֆունկցիան սխալի սկիզբն է։

Երկրորդ՝ անդամակցությունը գալիս է սեսիայից

Գտեք նույնականացված օգտատիրոջ ակտիվ անդամակցությունները և համեմատեք դրանք առաջին ստուգման վարձակալի հետ։ Երկու կլինիկաներին պատկանող օգտատերը կարող է փոխել, բայց փոխումը պետք է լինի հարցման համատեքստում գրանցված հստակ գործողություն, ոչ թե URL-ից արված եզրակացություն։ Մեկ կլինիկային պատկանող և մյուսը պահանջող օգտատիրոջը մերժում են, ներառյալ ներբեռնումները և API կանչերը։

Փորձարկեք բացասական դեպքը՝ խմբագրելով գրառման նույնացուցիչը և վարձակալի պարամետրը։ Եթե փոփոխություններից որևէ մեկը տվյալներ վերադարձնի, ապա շրջանակը կարդացվում է հարցումից, այլ ոչ թե հաստատված անդամակցությունից։

Cookie-ի շրջանակը և միասնական մուտքը որոշում են, թե որտեղ կարելի է ներկայացնել հաշիվը։ Նրանք չեն որոշում, թե ինչ կարող է կարդալ այդ հաշիվը։

Երրորդ՝ ցանցը ոչինչ չի ապացուցում մարդու մասին

VPN դարպասը նույնականացնում է թունելը, իսկ հանրային թույլատրելիների ցանկը՝ հասցեների տիրույթը։ Ոչ մեկը մարդու չի նույնականացնում։ NAT-ը շատ օգտատերերի հավաքում է մեկ աղբյուրի հասցեում, և գրասենյակային տիրույթը նույնն է անում շենքի բոլորի համար։ Վերաբերվեք երկուսին էլ որպես փոխադրման փաստերի և թույլտվությունը պահեք հավելվածում կամ ինտեգրացիայում, որը բացահայտ հայտարարում է ինքնությունը և այդպիսին էլ վերանայվում է։

DNS-ը երրորդ փոխադրման փաստն է։ Մասնավոր պատասխանը պահանջում է մասնավոր ուղի, իսկ հանրային ճակատը՝ աջակցվող ծագման ուղի։ Նրանցից ոչ մեկը թույլտվություն չի կրում։

Մեկ նախադասություն պատին՝ ցանցը որոշում է, թե ինչպես է հարցումը հասնում, իսկ հավելվածը որոշում է, թե ինչ կարող է կարդալ այն։

Չորրորդ՝ գործարկեք մատրիցը երկու մուտքերում

Օգտագործեք վերահսկվող հաշիվներ՝ փորձարկելու A-ն A-ում, B-ն B-ում, A-ն B-ում, անհայտ հոսթի անուն և առանց անդամակցության նույնականացված հաշիվ։ Չորրորդն ու հինգերորդը պետք է ձախողվեն փակ վիճակում և երբեք չընկնեն լռելյայն վարձակալի։ Գործարկեք նույն մատրիցը նաև VPN մուտքով՝ յուրաքանչյուր հաշվի համար մեկ սեսիոն տարայով:

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

Այնուհետև փոխեք թույլատրելիների ցանկի մի գրառում և կրկին գործարկեք։ Տեղաշարժվող արդյունքը նշանակում է, որ ցանցային հսկիչը թույլտվության որոշում է կայացնում։

Կրկնեք մատրիցը ճակատի ցանկացած փոփոխությունից հետո, քանի որ ստուգումը բաց թողնող երկրորդ կոդային ուղին այս սահմանի էրոզիայի ամենատարածված ձևն է։ Սպասվող արդյունքը ձանձրալի է. ամեն մուտք տալիս է նույն պատասխանները։