Umumiy subdomenlar, ikki kirish: qaysi yozuvlarni kim ko'radi?

Klinika A va Klinika B bitta kod bazasini, ikkita subdomenni va ofisdan hamda VPN orqali keladigan tashrif buyuruvchilar aralashmasini baham ko'radi. Tarmoq jamoalari odatda ikkala kirishni alohida sozlaydi va bu joyida, ilova buni qilmasa. Quyidagi tekshiruvlar ilovada bo'lishi va so'rov qaysi eshikdan kelganidan qat'i nazar bir xil ishlashi kerak.

Birinchisi: xost nomi faqat ijarachini nomlaydi

So'ralgan xost nomini administrator yuritadigan xaritalash bo'yicha hal qiling va noma'lum bo'lgan hamma narsani rad eting. Xom sarlavha o'rniga freymvorkning tasdiqlangan xost qiymatidan foydalaning, shunda soxta Host qidiruv kalitini kirita olmaydi. Muvaffaqiyatli moslik kodga qaysi ijarachi konfiguratsiyasi va qaysi brendni yuklashni aytadi. Lekin chaqiruvchi o'sha ijarachining ma'lumotlarini ko'ra olishini aytmaydi. Bu ikkinchi savolni alohida kiritishga ega alohida funksiyada saqlang.

Bitta xost nomi qidiruvidan ham kontekstni, ham ruxsatni qaytaradigan umumiy yordamchi funksiya xatoning boshlanishi.

Ikkinchisi: a'zolik sessiyadan keladi

Tasdiqlangan foydalanuvchining faol a'zoliklarini toping va ularni birinchi tekshiruvdagi ijarachi bilan solishtiring. Ikkala klinikaga ham tegishli foydalanuvchi almashtirishi mumkin, lekin almashtirish URLdan olingan xulosa emas, so'rov kontekstida qayd etilgan aniq harakat bo'lishi kerak. Bitta klinikaga tegishli bo'lib, boshqasini so'ragan foydalanuvchi rad etiladi, yuklab olishlar va API chaqiruvlari ham shu jumladan.

Salbiy holatni yozuv identifikatori va ijarachi parametrini o'zgartirib sinab ko'ring. Agar ikkala o'zgarishdan biri ma'lumot qaytarsa, qamrov tasdiqlangan a'zolikdan emas, so'rovdan o'qilmoqda.

Cookie qamrovi va yagona kirish hisob qayerga taqdim etilishini belgilaydi. Ular bu hisob nima o'qishi mumkinligini belgilamaydi.

Uchinchisi: tarmoq inson haqida hech narsani isbotlamaydi

VPN shlyuzi tunnelni autentifikatsiya qiladi, ochiq ruxsat ro'yxati esa manzillar diapazonini autentifikatsiya qiladi. Hech biri shaxsni aniqlamaydi. NAT ko'plab foydalanuvchilarni bitta manba manzilida jamlaydi, ofis diapazoni esa binodagi barchaga xuddi shunday qiladi. Ikkalasini ham tashish fakti sifatida qabul qiling va avtorizatsiyani ilovada saqlang, yoki shaxsni aniq e'lon qiladigan va shunga ko'ra ko'rib chiqiladigan integratsiyada saqlang.

DNS uchinchi tashish faktidir. Xususiy javob xususiy marshrutni talab qiladi, ochiq old qism esa qo'llab-quvvatlanadigan manba yo'lini talab qiladi. Ularning hech biri ruxsat olib yurmaydi.

Devorga ilinadigan bitta gap: tarmoq so'rov qanday kelishini, ilova esa nima o'qish mumkinligini hal qiladi.

To'rtinchisi: matritsani ikkala kirishda ham ishga tushiring

Boshqariladigan hisoblar bilan A ni A da, B ni B da, A ni B da, noma'lum xost nomini va a'zoligi yo'q tasdiqlangan hisobni sinab ko'ring. To'rtinchi va beshinchi yopiq holda muvaffaqiyatsiz bo'lishi va hech qachon standart ijarachiga tushmasligi kerak. Xuddi shu matritsani VPN kirishidan ham ishga tushiring, har bir hisob uchun bitta sessiya idish bilan:

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

Keyin ruxsat ro'yxatidagi bitta yozuvni o'zgartiring va qayta ishga tushiring. Siljigan natija tarmoq nazorati avtorizatsiya qarorini qabul qilayotganini anglatadi.

Old qismdagi har qanday o'zgarishdan keyin matritsani takrorlang, chunki tekshiruvni chetlab o'tadigan ikkinchi kod yo'li bu chegara eroziyasining eng keng tarqalgan usuli. Kutilgan natija zerikarli: har bir kirish bir xil javoblarni beradi.