-imageId orqali qidirish muammosini aniqlashdan cineroomId asosidagi kirish nazorati va develop/stg muhitlaridagi validatsiyagacha-
1. Umumiy ma’lumot
Bu ish proms-image loyihasida image resurslariga kirish ruxsatlarini ko‘rib chiqish jarayonida boshlandi. Dastlab vazifa faqat rasmlar muayyan ekranlarda to‘g‘ri ko‘rsatilayotganini hamda yuklash va qidirish jarayonlari xatosiz ishlayotganini tekshirishdan iborat deb o‘ylagandim. Biroq amaliy tekshiruv vaqtida rasmga egalik qiluvchi shifoxona bilan so‘rov yuboruvchining shifoxonasi mos kelmasa ham, rasmni olish mumkin bo‘lgan muammoni takrorladik.
proms-image e’lonlar, shifoxona ro‘yxatdan o‘tkazish rasmlari, tibbiy so‘rovnoma rasmlari va AMIS so‘rovnoma shabloni rasmlari kabi bir nechta funksiyalar o‘rtasida ulashiladigan rasmlarni saqlash va olish uchun javob beradi. Shuning uchun rasmning bitta ekranda to‘g‘ri ko‘rsatilishini tasdiqlashning o‘zi yetarli emas edi. Shuningdek, rasm qaysi shifoxona yoki cineroom ga tegishli ekanini va so‘rov yuboruvchi ushbu resursni ko‘rish huquqiga ega yoki ega emasligini tekshirishimiz kerak edi.
Ushbu maqolada amaliy ish davomida aniqlangan rasm egasini validatsiya qilish yetishmasligi muammosini qanday takrorlaganimiz, qaysi kod yo‘llarini o‘zgartirganimiz hamda o‘zgarishlarni develop va stg muhitlarida qanday tekshirganimiz bayon qilinadi. Ichki identifikatorlar va haqiqiy servis yo‘llari faqat tushuntirish uchun zarur bo‘lgan joylarda ishlatiladi; asosiy e’tibor xavfsizlik muammosini aniqlash va bartaraf etish jarayoniga qaratilgan.
2. Muammo: faqat imageId orqali qidirish xavfi
Asosiy muammo rasmlarni olishda resurslarni faqat imageId yordamida topadigan yo‘l mavjud bo‘lgani edi. imageId UUID asosida bo‘lib, uni tasodifiy topish oson bo‘lmasa-da, uni ichki javoblar, ekran HTML kodi, loglar yoki boshqa API javoblari orqali bilib olish mumkin. Shuning uchun haqiqiy tokeniga ega foydalanuvchi imageId ni bilsa, o‘z shifoxonasiga tegishli bo‘lmagan rasmni olishi mumkin edi.
Mavjud tuzilmani soddalashtirib ko‘rsatsak, u quyidagicha edi.
// 기존 조회 흐름 예시
public ImageFile findImageFile(String imageId) {
return imageFileStore.retrieve(imageId);
}
public ImageFile retrieve(String imageId) {
return imageFileJpaRepository.findById(imageId)
.map(ImageFileJpo::toDomain)
.orElse(null);
}Ushbu tuzilmada cineroom_id DB dagi image_file jadvalida saqlangan bo‘lsa-da, amaldagi qidirish shartiga kiritilmagan edi. Boshqacha aytganda, rasm p-1-c-2 ga tegishli sifatida saqlangan bo‘lsa ham, p-1-c-1 foydalanuvchisi uning imageId i bilan so‘rov yuborib, rasmni olishi mumkin edi.
Xavfsizlik nuqtayi nazaridan bu shunchaki qidirishdagi xato emas, balki resurs egasini validatsiya qilmaslik edi. Autentifikatsiyadan o‘tgan foydalanuvchilar ham barcha resurslarga avtomatik ravishda kirish huquqiga ega bo‘lmaydi. Ma’lumotlar shifoxona yoki tashkilot bo‘yicha ajratilgan servisларда resursning egalik doirasi hamisha tekshirilishi kerak.
3. Muammo qanday aniqlandi
Muammoni tekshirish uchun avval develop muhitida p-1-c-1 foydalanuvchisi yordamida e’lon rasmini yukladik. Yuklashdan so‘ng DB da rasm image_file jadvalida saqlanganini va cineroom_id p-1-c-1 ga o‘rnatilganini tasdiqladik.
Keyin xavfsizlik validatsiyasi uchun tegishli rasm qatorining faqat cineroom_id qiymatini p-1-c-2 ga o‘zgartirdik. Shu holatda o‘sha p-1-c-1 foydalanuvchisi yordamida ayni e’lonni qayta oldik. Kutilgan xatti-harakat rasm yashirilishi yoki 404 javobi bilan bloklanishi edi. Biroq mavjud develop muhitida rasm avvalgidek ko‘rsatishda davom etdi.
Brauzer keshini istisno qilish uchun hard refresh bajardik va Network yorlig‘ida rasmni qidirish so‘rovi 200 OK qaytarganini tasdiqladik. So‘rov sarlavhasidagi X-Tenant-Id p-1-c-1 edi, DB dagi rasmning cineroom_id qiymati esa p-1-c-2 edi. Bu mavjud mantiq so‘rov yuboruvchining cineroomId qiymatini rasmning cineroomId qiymati bilan solishtirmaganini aniq tasdiqladi.
-- 재현을 위한 DB 변경 예시
update image_file
set cineroom_id = 'p-1-c-2'
where id = '테스트_image_id';
select id, cineroom_id, original_name, valid_yn
from image_file
where id = '테스트_image_id';Ushbu takrorlash muammoning mohiyatini aniqlashtirdi. Bu shunchaki rasm muayyan ekranda noto‘g‘ri ko‘rsatilishi muammosi emas edi; imageId orqali yolg‘iz qidirishga imkon beradigan barcha yo‘llarni topishimiz kerak edi.
4. Asosiy sabab tahlili: qidirish yo‘li bittadan ko‘p edi
Dastlab faqat e’lon rasmlarini qidirish API sini o‘zgartirish yetarli bo‘lib ko‘rinishi mumkin. Biroq proms-image bir nechta funksiyalar tomonidan umumiy komponent sifatida chaqirilardi va rasmlarni qidirishning bir nechta usuli mavjud edi. Asosiy usullar imageId bo‘yicha qidirish, imageId lar ro‘yxati bo‘yicha qidirish hamda fileId + fileNo bo‘yicha qidirish edi.
E’lon rasmlari va shifoxonani ro‘yxatdan o‘tkazish rasmlari kabi imageId dan bevosita foydalanadigan yo‘llarni kuzatish nisbatan oson edi. Aksincha, tibbiy so‘rovnoma rasmlari va AMIS so‘rovnoma shabloni rasmlarida fileId va fileNo asosida mavjud rasmlardan qayta foydalanadigan yo‘llar bor edi. Dastlabki o‘zgartirish doirasida bu yo‘lni o‘tkazib yuborish oson edi. Darhaqiqat, tibbiy so‘rovnomani yuklash testlari vaqtida cineroom_id ni o‘zgartirgandan keyin ham rasm olinayotganini aniqladik, bu esa qo‘shimcha tuzatishlar zarurligini tasdiqladi.
Asosiy sabab tahlili o‘zgartirish talab qilinadigan ikkita asosiy yo‘nalishni aniqladi.
-
Umumiy rasmni qidirish/yangilash/o‘chirish yo‘llarida faqat imageId orqali qidirish olib tashlanib, uning o‘rniga imageId + cineroomId yordamida qidirish joriy qilinishi kerak edi.
-
Tibbiy so‘rovnoma rasmlari metama’lumotlarini qidirish yo‘lida faqat fileId + fileNo orqali qidirish olib tashlanib, uning o‘rniga cineroomId + fileId + fileNo yordamida qidirish joriy qilinishi kerak edi.
-
proms-image-client dan foydalanadigan proms-survey va proms-amc-seoul-adapter ham yangi so‘rov formatiga muvofiq cineroomId ni uzatishi kerak edi.
5. O‘zgartirish yo‘nalishi: so‘rov yuboruvchining cineroomId qiymatini resursning cineroomId qiymati bilan birga validatsiya qilish
O‘zgartirish yo‘nalishi sodda edi. Rasm resursini olayotganda faqat imageId yoki fileId + fileNo bo‘yicha qidirmasdan, qidirish shartiga doimo so‘rov yuboruvchining cineroomId qiymatini ham kiritish kerak edi. So‘rov yuboruvchining cineroomId qiymati server boshqaradigan foydalanuvchi kontekstidan olindi.
Qidirish sharti o‘zgartirilgach, boshqa cineroom ga tegishli rasmlar DB dan olinmaydigan bo‘ldi. “Ruxsat berilmadi” holatini “topilmadi” holatidan farqlash resurs mavjudligini oshkor qilishi mumkinligi sababli, boshqa cineroom ga tegishli rasmlarga kirishni mavjud bo‘lmagan rasm bilan bir xil tarzda 404 Not Found sifatida qayta ishlashni tanladik.
// 수정 방향 예시
String cineroomId = requesterCineroomId();
ImageFile imageFile = imageFileLogic.findImageFile(imageId, cineroomId);
if (imageFile == null) {
throw new ImageResourceNotFoundException();
}Ushbu yondashuvning afzalligi validatsiya mas’uliyati aniq bo‘lishidir. Frontend yuborgan tasodifiy qiymatlarga tayanish o‘rniga, resursga kirish doirasi server tan olgan so‘rov yuboruvchi konteksti asosida cheklanadi. Bundan tashqari, so‘rov DB qidirish bosqichida bloklangani uchun MinIO kabi haqiqiy fayl saqlash tizimiga murojaat qilishdan oldin to‘xtatilishi mumkin.
6. Umumiy rasmni qidirish/yangilash/o‘chirish yo‘llarini yaxshilash
Umumiy rasm yo‘llari uchun repository, store, domain logic va feature load/flow qatlamlarini birgalikda o‘zgartirdik. Asosiy o‘zgarish mavjud findById yoki findByIdIn qidiruvlarini findByIdAndCineroomId va findByIdInAndCineroomId shartlari bilan almashtirish edi.
// Repository 조회 조건 추가 예시
Optional<ImageFileJpo> findByIdAndCineroomId(String id, String cineroomId);
List<ImageFileJpo> findByIdInAndCineroomId(Collection<String> ids, String cineroomId);Qidirish mantiqida so‘rov yuboruvchining activeCineroomId qiymatini oldik va uni imageId bilan birga uzatdik. Xuddi shu standart yangilash va o‘chirish yo‘llariga ham tatbiq etildi. Agar faqat qidirish bloklanib, yangilash va o‘chirish hali ham faqat imageId orqali bajarilsa, foydalanuvchilar boshqa tomonlarga tegishli resurslarni o‘zgartirishi yoki o‘chirishi mumkin bo‘lardi.
// Domain logic 예시
@Transactional(readOnly = true)
public ImageFile findImageFile(String imageId, String cineroomId) {
return imageFileStore.retrieveByIdAndCineroomId(imageId, cineroomId);
}
@Transactional(readOnly = true)
public List<ImageFile> findByIdIn(Collection<String> ids, String cineroomId) {
return imageFileStore.retrieveByIdInAndCineroomId(ids, cineroomId);
}Bu jarayonda mavjud tizim standart rasmi uchun fallback yo‘lini ehtiyotkorlik bilan ko‘rib chiqdik. Agar kontekst validatsiyasi har bir yo‘lga shartsiz qo‘shilsa, shablonlar, tizim standart rasmlari hamda tashqi yoki umumiy chaqiruv yo‘llariga ta’sir qilishi mumkin edi. Shu sababli o‘zgarishlarni umumiy foydalanuvchi rasmlarini qidirish/yangilash/o‘chirish yo‘llariga qaratdik va umumiy shablon yo‘llarini ularning haqiqiy chaqiruv maqsadi hamda ta’sir doirasiga ko‘ra ajratdik.
7. activeCineroomId mavjud bo‘lmagan so‘rovlarni himoyalangan tarzda qayta ishlash
Test davomida alohida muammoni ham aniqladik. Brauzerning login yoki tenant konteksti nomuvofiq holatda bo‘lgan paytda rasm yuklash so‘rovi yuborilsa, X-Tenant-Id to‘g‘ri yaratilmas va server kontekstidagi activeCineroomId bo‘sh bo‘lishi mumkin edi. Mavjud kod esa to‘g‘ridan-to‘g‘ri Optional.get() ni chaqirib, NoSuchElementException ga sabab bo‘lardi va yakunda 500 Internal Server Error qaytarilardi.
Bu muammo H-2 egalik validatsiyasi muammosi bilan aynan bir xil bo‘lmasa-da, xuddi shu ish davomida aniqlangan yana bir himoyalangan tarzda qayta ishlash holati edi. Tushunarsiz 500 xatosini qaytarish o‘rniga, shifoxona tanlovi haqidagi ma’lumotni tasdiqlab bo‘lmaganini aniq bildiradigan maxsus exception qo‘shdik.
public class ActiveCineroomNotFoundException extends RuntimeException {
public ActiveCineroomNotFoundException() {
super("병원 선택 정보가 확인되지 않습니다. 다시 로그인 후 이용해 주세요.");
}
}
private String requesterCineroomId() {
PromsUserContext context = StageContextHolder.getContext();
if (context == null || context.getActiveCineroomId().isEmpty()) {
throw new ActiveCineroomNotFoundException();
}
return context.getActiveCineroomId().get();
}Exception proms-image ga xos handler tomonidan qayta ishlandi. common-core dagi umumiy exception bilan ishlash mantiqini o‘zgartirish boshqa servislarga ta’sir qilishi mumkin edi, shuning uchun avval proms-image ni faqat o‘ziga kerakli exception larni ushlaydigan qilib sozladik.
8. Tibbiy so‘rovnoma rasmlarining fileId + fileNo orqali qidirish yo‘lini yaxshilash
E’lon va shifoxonani ro‘yxatdan o‘tkazish rasmlari bilan bog‘liq muammo imageId asosidagi qidiruvlarni bloklash orqali hal qilindi. Biroq tibbiy so‘rovnomalarni yuklashda muammo yana yuzaga chiqdi. Tibbiy so‘rovnoma rasmlarini qidirish yo‘li imageId o‘rniga fileId va fileNo asosida mavjud rasmlarni izlardi. Bu holatda image_file.cineroom_id p-1-c-2 ga o‘zgartirilgan bo‘lsa ham, fileId + fileNo mos kelar ekan, mavjud qator qayta ishlatilishi mumkin edi.
Buni hal qilish uchun proms-image-client dagi ClientFindImageByFileIdAndFileNoQuery ga cineroomId maydonini qo‘shdik va serverdagi qidirish shartini cineroomId + fileId + fileNo ko‘rinishiga o‘zgartirdik.
public class ClientFindImageByFileIdAndFileNoQuery {
private String cineroomId;
private String fileId;
private String fileNo;
}
// Repository 조회 조건 추가 예시
Optional<ImageFileJpo> findByCineroomIdAndFileIdAndFileNo(
String cineroomId,
String fileId,
String fileNo
);Bu o‘zgarishni faqat proms-image ni o‘zgartirish orqali yakunlab bo‘lmas edi. proms-image-client dan foydalanadigan servislar ham yangi so‘rov formatiga muvofiq cineroomId ni uzatishi kerak edi. Haqiqiy ta’sir doirasini tekshirgach, ushbu mijozdan proms-survey va proms-amc-seoul-adapter foydalanishini aniqladik, shuning uchun ikkala servisga ham o‘zgartirish kiritish talab qilindi.
proms-survey da tibbiy so‘rovnoma tafsilotlarini qidirish jarayonini targetCineroomId ni ham uzatadigan qilib o‘zgartirdik. proms-amc-seoul-adapter da AMIS so‘rovnoma shablonini qidirish jarayonini shifoxonaning cineroomId qiymatini ham uzatadigan qilib o‘zgartirdik.
// proms-survey 호출부 예시
imageLoadProxyService.findImageByFileIdAndFileNo(
targetCineroomId,
fileId,
fileNo
);
// proms-amc-seoul-adapter 호출부 예시
String cineroomId = HospitalTenant.CINEROOM.getValue();
imageLoadProxyService.findImageByFileIdAndFileNo(
cineroomId,
vo.getImageFileId(),
vo.getImageFileNo()
);9. Mijoz modulini deploy qilish va integratsiyalashgan servislar ta’sir doirasi
Ushbu o‘zgartirishda eng ko‘p ehtiyotkorlikni talab qilgan qism proms-image-client ni deploy qilish edi. proms-survey va proms-amc-seoul-adapter Nexus ga deploy qilingan com.proms:proms-image-client kutubxonasidan foydalanardi. Shu sababli mijoz DTO maydonlari va konstruktorlaridagi o‘zgarishlar ushbu mijoz versiyasidan foydalanuvchi servislardagi kompilyatsiyaga ham ta’sir qilishi mumkin edi.
Mavjud versiyani ustiga yozishni tanlamadik. main va develop bir xil Nexus ga murojaat qilgani sababli, mavjud artifact tarkibini o‘zgartirish kutilmagan servislarga yangi DTO ni olib kelishi mumkin edi. Shuning uchun proms-image-client ning baseVersion qiymatini 1.0.4 ga oshirdik, release versiyasi Nexus ga muvaffaqiyatli deploy qilinganini tasdiqladik va keyin proms-survey hamda proms-amc-seoul-adapter ni aynan shu versiyadan foydalanadigan qilib sozladik.
// 연동 서비스 build.gradle 예시
implementation 'com.proms:proms-image-client:1.0.4' Deploy qilishdan oldin har bir repository dagi chaqiruv joylarini qidirdik. Agar findImageByFileIdAndFileNo(fileId, fileNo) ko‘rinishidagi ikki argumentli chaqiruvlar qolgan bo‘lsa, yangi mijozni qo‘llash kompilyatsiya xatolariga olib kelishi yoki xavfsizlik validatsiyasi to‘liq bajarilmasligi mumkin edi.
rg "findImageByFileIdAndFileNo\(" -n .
rg "new ClientFindImageByFileIdAndFileNoQuery" -n .
rg "proms-image-client" -n .Qidiruv natijalariga asoslanib, proms-survey va proms-amc-seoul-adapter dagi barcha chaqiruv joylarini uchta argumentdan foydalanadigan qilib o‘zgartirdik hamda build.gradle faylini proms-image-client 1.0.4 versiyasidan foydalanadigan qilib yangiladik.
10. develop va stg muhitlaridagi validatsiya natijalari
O‘zgartirishlardan so‘ng develop va stg muhitlarida ketma-ket validatsiya o‘tkazdik. Validatsiya nafaqat odatiy qidiruvlarni, balki test rasmidagi cineroom_id qiymati DB da boshqa shifoxonaga tegishli qiymatga o‘zgartirilgandan keyin kirish bloklangan-bloklanmaganini ham qamrab oldi. Har bir DB o‘zgarishi id asosida aynan bitta qatorga ta’sir qildi va testdan so‘ng darhol avvalgi holatiga qaytarildi.
10.1 E’lon rasmi validatsiyasi
E’lon rasmlari uchun p-1-c-1 foydalanuvchisi yordamida rasm yukladik va uning odatdagidek ko‘rsatilishini tasdiqladik. Keyin rasm qatoridagi cineroom_id qiymatini p-1-c-2 ga o‘zgartirdik va ayni foydalanuvchi orqali olinganda rasm ko‘rsatilmasligini tasdiqladik. O‘zgarishni qaytarganimizdan so‘ng rasm yana odatdagidek ko‘rsatildi.
10.2 Shifoxonani ro‘yxatdan o‘tkazish rasmi validatsiyasi
Shifoxonani ro‘yxatdan o‘tkazish yoki tenant rasmlari ham xuddi shu tarzda validatsiya qilindi. Avval odatiy qidiruvni tasdiqlagach, image_file.cineroom_id qiymatini p-1-c-2 ga o‘zgartirdik. Natijada rasmni p-1-c-1 foydalanuvchisi ola olmadi. Uni yana p-1-c-1 ga o‘zgartirgach, rasm odatdagidek olindi.
10.3 proms-survey so‘rovnoma rasmini tekshirish
proms-survey’da avval so‘rovnoma yuklanish ekranida so‘rovnomaga kiritilgan rasmlar to‘g‘ri ko‘rsatilayotganini tekshirdik. Rasmning cineroom_id qiymatini p-1-c-2 ga o‘zgartirgandan so‘ng, so‘rovnomani p-1-c-1 foydalanuvchisi sifatida ko‘rganimizda rasm ko‘rsatilmagan. O‘zgarishni qaytarganimizdan keyin rasm yana to‘g‘ri ko‘rsatildi. Bu cineroomId sharti so‘rovnoma rasmini olish yo‘liga ham qo‘llanganini tasdiqladi.
10.4 proms-amc-seoul-adapter AMIS so‘rovnoma shakli rasmini tekshirish
proms-amc-seoul-adapter’da buni bevosita ekranda tekshirish qiyin bo‘lgani uchun Postman yordamida AMIS so‘rovnoma shaklini olish API’sini chaqirdik. Ushbu yo‘lda rasm mavjud bo‘lmasa, asl AMIS faylini qayta olish va yangi rasm qatorini yaratish mumkin. Shuning uchun biz “rasm ko‘rinmayaptimi” degan savolni emas, balki “p-1-c-2 ga o‘zgartirilgan mavjud rasm qatori qayta ishlatiladimi” degan savolni tekshirdik.
Test natijalari mavjud p-1-c-1 rasm qatorining cineroom_id qiymatini p-1-c-2 ga o‘zgartirib, keyin uni o‘sha fileId + fileNo bilan qayta olganimizda, mavjud qator qayta ishlatilmaganini ko‘rsatdi. Buning o‘rniga p-1-c-1 uchun yangi rasm qatori yaratildi. Boshqa cineroom’ga tegishli rasm qayta ishlatilmagani va so‘ralgan cineroom asosida qayta ishlangani sababli, bu xatti-harakat to‘g‘ri deb topildi. Testdan so‘ng yangi yaratilgan qatorni tozaladik va mavjud qatorni avvalgi holatiga qaytardik.
-- adapter 검증 시 판단 기준 예시
-- OLD_IMAGE_ID: 기존 row, cineroom_id를 p-1-c-2로 변경
-- 동일 API 재호출 후 OLD_IMAGE_ID가 응답이나 재사용 경로에 나타나면 실패
-- OLD_IMAGE_ID가 재사용되지 않고 NEW_IMAGE_ID가 p-1-c-1로 생성되면 정상
select id, cineroom_id, file_id, file_no, original_name, valid_yn, registered_on
from image_file
where file_id = '테스트_file_id'
and file_no = '테스트_file_no'
order by registered_on desc;10.5 Clinical rasmini tekshirish holati
O‘sha vaqtda tibbiyot xodimlari va bemorlar o‘rtasidagi Clinical rasmlari ekraniga kirish cheklanganligi sababli, haqiqiy ekran asosida test o‘tkaza olmadik. Biroq kod asosida cineroomId’ga asoslangan olish mantiqi notice va so‘rovnoma rasmlaridagi kabi qo‘llanganini tasdiqladik. Kelajakda ekranga kirish imkoniyati paydo bo‘lsa, rasmlarni amalda yuklash, olish va boshqa cineroom’lardan kirishni bloklashni qo‘shimcha ravishda tekshirishni rejalashtiryapmiz.
11. Amalga oshirish jarayonida olingan saboqlar
Birinchi saboq — autentifikatsiya va avtorizatsiyani alohida ko‘rib chiqish kerak. Foydalanuvchida yaroqli token mavjudligi uning “tizimga kirgan foydalanuvchi” ekanini anglatadi; bu uning har qanday rasm resursiga kira olishini anglatmaydi. Ushbu muammo autentifikatsiya mavjud bo‘lgan, ammo resurs egaligini tekshirish mavjud bo‘lmagan holat edi.
Ikkinchi saboq — umumiy modulning ta’sir doirasi har doim tekshirilishi kerak. proms-image-client bir nechta servislar tomonidan ulashib ishlatiladigan kutubxona edi. Shu sababli mijoz DTO’sini o‘zgartirish faqat proms-image serverida emas, balki proms-survey va proms-amc-seoul-adapter kabi chaqiruvchi servislarda ham o‘zgarishlarni talab qildi. Bu bitta loyiha ichidagi o‘zgartirishdek ko‘rinsa-da, aslida bir nechta servislar o‘rtasidagi integratsiyani qamrab olgan o‘zgarish edi.
Uchinchi saboq — test mezonlari har bir funksiya uchun alohida belgilanishi kerak. Notice va shifoxonada ro‘yxatdan o‘tkazish rasmlari uchun “rasm ko‘rinmasligi kerak” to‘g‘ri tekshiruv mezoni edi. Aksincha, AMIS so‘rovnoma shakli rasmlari uchun asl faylga qaytish mexanizmi orqali yangi rasm yaratilishi mumkin edi. Shu sababli “boshqa cineroom’dan mavjud qator qayta ishlatilmasligi kerak” aniqroq mezon bo‘ldi.
To‘rtinchi saboq — xavfsizlikni tekshirish uchun DB’ni bevosita o‘zgartirganda, o‘zgarishni qaytarish tartibi testning o‘zi kabi muhimdir. develop va stg muhitlarida test o‘tkazganimizda, avval har doim maqsadli qatorni tekshirdik, faqat uning id qiymatiga asoslangan bitta qatorni o‘zgartirdik va testdan so‘ng darhol o‘zgarishni qaytardik. Yangi qator yaratilgan holatlarda muhit ifloslanishining oldini olish uchun test qatorini o‘chirdik yoki yaroqsiz holatga keltirdik.
Nihoyat, hatto kichik logni olib tashlash ham deployment nuqtayi nazaridan tekshirilishi kerak bo‘lishi mumkinligini yana bir bor angladim. ImageIoConfig’dan System.out.println’ni olib tashlash kabi funksional mantiqqa bevosita aloqador bo‘lmagan o‘zgarishlar uchun to‘liq regressiya testi zarur emas edi. Biroq yangi pod ishga tushganda standart chiqish logi endi ko‘rinmasligini tekshirishimiz mumkin edi.
12. Xulosa
Ushbu ish dastlab rasmlar to‘g‘ri ko‘rsatilayotganini oddiy tekshirish sifatida boshlandi, ammo oxir-oqibat rasm resurslariga egalikni tekshirishni keng qamrovli ko‘rib chiqishga aylandi. Muammo dastlab notice rasmlari bilan takrorlandi. Keyin so‘rovnomani yuklash va AMIS so‘rovnoma shaklini olish yo‘llarini tekshirar ekanmiz, nafaqat imageId asosidagi olishni, balki fileId + fileNo asosidagi qayta ishlatish yo‘lini ham yaxshilash kerakligini angladik.
Yakunida proms-image’da imageId yoki fileId + fileNo yordamida mustaqil olishni olib tashladik va cineroomId shartini ham o‘z ichiga oladigan qilib o‘zgartirdik. proms-image-client 1.0.4 versiyasi sifatida chiqarildi. Undan foydalanadigan proms-survey va proms-amc-seoul-adapter ham cineroomId uzatadigan qilib o‘zgartirildi. develop va stg muhitlarida notice, shifoxonada ro‘yxatdan o‘tkazish, so‘rovnomani yuklash va AMIS so‘rovnoma shaklini olish holatlarida rasmlarning normal olinishi hamda boshqa cineroom’larga tegishli rasmlarning bloklanishi yoki qayta ishlatilmasligini tekshirdik.
Ushbu tajriba orqali xavfsizlik muammolarini kodning faqat bitta qatoriga qarab baholash qiyinligini angladim. Hatto bir xil rasm resursi uchun ham kirish yo‘li ekran, API, saqlash usuli va qaytish mexanizmiga qarab farq qilishi mumkin. Shuning uchun xavfsizlik tuzatishi faqat “muammo yuz bergan ekran”ni qamrab olmasligi kerak; u ayni resursga olib borishi mumkin bo‘lgan barcha yo‘llarni kuzatib chiqishi va har bir yo‘lga mos tekshiruv mezonlarini belgilashi lozim.
Kelajakda shunga o‘xshash umumiy resurslarni olish funksiyalarini amalga oshirganda, resurs egasi, so‘rov yuboruvchi konteksti, olish shartlari, xatoga javob berish siyosati va mijozlarga ta’sir doirasini boshidanoq tekshirish odatini shakllantirishim kerakligini his qildim. Ushbu ish rasm xavfsizligi muammosini hal qilish tajribasi bo‘lish bilan birga, MSA muhitida umumiy mijoz o‘zgarishlarini boshqarish va bir nechta servislar bo‘ylab tekshirishni o‘rgangan holatim ham bo‘ldi.
Ilova. Tekshiruv ro‘yxati
-
Notice rasmlari: normal olish, boshqa cineroom’ga o‘zgartirilganda bloklanish va o‘zgarish qaytarilgandan keyin normal olinishi tekshirildi.
-
Shifoxonada ro‘yxatdan o‘tkazish rasmlari: normal olish, boshqa cineroom’ga o‘zgartirilganda bloklanish va o‘zgarish qaytarilgandan keyin normal olinishi tekshirildi.
-
proms-survey so‘rovnoma rasmlari: cineroom_id o‘zgartirilganda rasm ko‘rsatilmasligi va o‘zgarish qaytarilgandan keyin normal ko‘rsatilishi tekshirildi.
-
proms-amc-seoul-adapter AMIS so‘rovnoma shakli rasmlari: boshqa cineroom’ga tegishli qator qayta ishlatilmagani va so‘ralgan cineroom asosida yangi qator yaratilgani tekshirildi.
-
proms-image-client: 1.0.4 reliz versiyasi Nexus’ga joylashtirilgani tekshirildi.
-
proms-survey va proms-amc-seoul-adapter: proms-image-client 1.0.4 versiyasidan foydalanish va uchta argumentli chaqiruv formati tekshirildi.
-
develop va stg DB’larida o‘zgartirilgan test ma’lumotlari qaytarildi.
wade