728x90 전체 글28 HTTPS 리다이렉트 무한 루프 — 앱이 원래 프로토콜을 모르기 때문이다 HTTPS 리다이렉트가 무한 루프를 돌면, 원인은 대개 앱이 원래 요청의 프로토콜을 모른다는 것이다.로드밸런서가 TLS를 끊고 뒤로는 HTTP로 넘기면 앱은 "이건 HTTP다"라고 본다. 그래서 HTTPS로 리다이렉트하고, 브라우저가 HTTPS로 다시 오면 로드밸런서는 또 HTTP로 넘긴다. 끝나지 않는다.로드밸런서는 원래 프로토콜을 헤더로 알려준다. 앱이 그 헤더를 안 믿도록 설정돼 있는 게 문제다.루프가 도는 순서한 바퀴를 따라가면 원인이 보인다.1. 브라우저 → https://example.com/ (HTTPS)2. 로드밸런서: TLS 종료, 뒤로는 HTTP 로 전달3. 앱: "HTTP 요청이네" → 301 https://example.com/4. 브라우저 → https://example.. 2026. 9. 28. 프론트 검증은 UX지 보안이 아니다 — 서버 검증 누락이 남긴 것 회원 포인트 잔액을 세어 보니 음수인 회원이 40여 명이었다. 합계 약 -2,200만 원. 가진 것보다 많이 쓴 것이다. 사용액이 잔액을 넘는지 보는 검사가 자바스크립트 한 군데에만 있었다. 컨트롤러·서비스·매퍼 어디에도 하한 검사가 없었다. 에러가 안 나기 때문에 아무도 몰랐다. 음수 잔액도 숫자라서 화면에 그대로 찍히고, 시스템은 정상 동작으로 본다.검증이 화면에만 있었다코드를 훑었다. 사용액이 잔액을 넘는지 보는 곳은 딱 한 군데였다.// res004Common.jsif (Number(usePoint) > Number(balance)) { alert(MESSAGE.MSG0026); // "보유 포인트를 초과했습니다" return false;}저장 쿼리는 이렇게 생겼다.-- 직전 잔액에.. 2026. 9. 28. 3분짜리 캡처로 정한 대역이 점포 아홉 곳의 전화를 끊었다 옛 박스는 그 포트가 0.0.0.0/0이었다. 새로 만들면서 "전 세계 개방은 아니지"라며 통신사 대역 세 개로 좁혔는데, 근거가 3분짜리 패킷 캡처 5건이었다.전환하고 열흘 뒤 점포 아홉 곳의 전화 수신이 끊겼다. 5xx도 타임아웃도 실패 로그도 없었다. 요청이 박스에 도달조차 못 했기 때문이다.보안 그룹에서 막힌 트래픽은 아무 데도 안 남는다. 그래서 고객 신고로만 알 수 있었다.사건 — 전화가 안 들어오는데 아무 알람도 없었다어떻게 알았나고객사에서 전화가 와서 알았다. 오전 11시 20분경.전환 직후부터 끊겨 있었는데 그때까지 아무도 몰랐다. 요청이 네트워크 계층에서 끊기면 애플리케이션 로그에 아무것도 안 남는다.먼저 세운 가설이 틀렸다같은 시기에 이중화를 붙였으니 그쪽을 의심했다. 두 대로 늘렸는.. 2026. 9. 28. PostgreSQL 인덱스 재구성 시점 — 달력이 아니라 밀도로 정한다 PostgreSQL 인덱스는 주기적으로 재구성할 필요가 없다. 공식 문서도 B-tree에 정기 재구성이 필요하다고 말하지 않는다.재구성이 값어치를 하는 건 특정 사용 패턴일 때다. 각 범위에서 대부분의 키가 지워지는데 몇 개만 남는 패턴이면 페이지가 계속 할당된 채 남아 공간이 낭비된다.그러니 달력이 아니라 측정값으로 판단한다. pgstatindex의 avg_leaf_density를 보면 지금 재구성할 값어치가 있는지 나온다.언제 재구성이 필요한가문서가 드는 경우는 넷이다.인덱스가 손상됐을 때 — 소프트웨어 버그나 하드웨어 장애로 유효한 데이터를 잃은 경우인덱스가 부풀었을 때 — 비었거나 거의 빈 페이지가 많아진 경우저장 파라미터를 바꿨을 때 — fillfactor 같은 값을 바꾸고 완전히 반영하고 싶을.. 2026. 9. 21. 차단했는데 12시간을 더 쓴다 — 세션 인증에는 무효화가 없다 계약이 끝난 점포의 계정을 전부 "사용 안 함"으로 바꿨는데, 이미 로그인해 있는 사람은 그대로 쓸 수 있었다. 세션 만료(12시간)까지 정상 사용자다.버그가 아니라 세션 인증의 성질이다. 로그인할 때 한 번 검증하고 그 뒤로는 세션이 있다는 것만으로 인증된 요청이 된다. 발급한 것을 회수하는 경로는 따로 만들어야 한다.그리고 세션을 지우려다 엉뚱한 걸 지울 뻔했다. 삭제 기준으로 잡은 속성이 "그 사람이 누구인지"가 아니었다.세션 인증에는 "무효화"가 없다로그인 시점에 계정을 검증하고, 통과하면 세션에 사용자 정보를 담는다. 그 다음부터는 세션이 있다는 것만으로 인증된 요청이 된다.요청마다 하는 검사는 이 정도다.// 요청한 점포와 세션의 점포가 같은지if (!requestOffice.equals(se.. 2026. 9. 21. 전환 뒤에 켜진 알람들 — 새 문제가 아니라 원래 있던 것이 보인 것 새 구조로 넘긴 직후부터 오류 알림이 꾸준히 왔다. 전환 전 11일간 같은 오류가 0건이었으니 전환이 만든 것으로 보였고, 실제로 그렇게 보고 하루를 썼다.결론부터 쓰면 둘 다 전환이 만든 것이 아니라 전환이 드러낸 것이었다. 하나는 3년간 감시 밖이었던 서비스, 하나는 옛 구조에서 다른 이름으로 기록돼 아무도 안 보던 장애다.전환 전 "0건"은 정상의 근거가 아니다. 오래 조용한 것은 건강한 게 아니라 안 보이는 것일 수 있다.사건 1 — 푸시 오류: 감시가 없었을 뿐이다알림은 이렇게 왔다com.google.firebase.messaging.FirebaseMessaging$3 - https://fcm.googleapis.com/...서비스명 자리에 클래스명이 있고, 오류 자리에 URL만 있다. 상태코드.. 2026. 9. 21. 이전 1 2 3 4 5 다음 728x90