보안테스트 결과 XSS 취약점이 발견돼 조치를 하면서, 약간 고생을 해서 경험을 공유해보려 한다. XSS(Cross Site Scripting) 악의적인 사용자가 공격하려는 사이트에 스크립트를 넣는 기법 XSS Filter 현재 백엔드 프로젝트가 Rest API로 구성돼, 대부분의 요청과 응답이 json 방식으로 요청 중이다. Spring XSS를 검색하면 가장 많이 노출되는 Lucy Filter가 있지만, @ResponseBody로 응답되는 application/json 타입은 처리하지 못한다고 해서 Jackson 라이브러리의 CharacterEscape를 설정해 , ', " 총 4개의 문자를 치환했었다. 관련된 설정은 https://jojoldu.tistory.com/470을 참고했다. 위의 설정으로..
서비스 가동중에 프로퍼티를 변경할 수 있으면, 서비스를 배포하지 않아도 되기 때문에 빠르고 유연한 서비스를 운영할 수 있다. 스프링에서 제공하는 spring actuator를 의존하는 것만으로도 쉽게 적용할 수 있다. 설정 의존성 추가 # build.gradle dependencies { implementation 'org.springframework.boot:spring-boot-starter-actuator' } 프로퍼티 설정 # application.yml management: endpoints: web: exposure: include: refresh 이렇게만 설정하면 끝이다. 프로퍼티를 변경할 일이 생기면 application.yml을 변경하고 actuator에서 제공하는 엔드포인트를 호출하기만..
코드를 보다 보니 날짜를 의미하는 데이터를 마이바티스->어플리케이션 맵핑하는 방식이 다양한 것을 봤다. 내 기억으로는 특정 마이바티스 버전부터는 자동으로 [LocalDateTime, LocalDate, LocalTime]으로 맵핑해 주는 걸로 알고 있었는데 활용하지 못한 것처럼 보여 의아했다. 이유를 알아보니 기존 레거시 코드를 그대로 옮기다 보니 그런 것도 있지만, 현재 환경이 위의 Java 타입으로 맵핑이 깔끔하게 되지는 않기 때문이었다. 데이트 타입 맵핑 장애물 오라클DB 날짜 타입 먼저 현재 환경은 오라클과 비슷한 국산DB 티베로를 사용하고 있다(이 글에서 말하려는 특징은 동일하기 때문에 오라클로 설명하겠다). 오라클 날짜 형식의 데이터는 4가지로 분류된다. DATE 연, 월, 일, 시, 분, 초..
Vim으로 통일 백엔드 개발자에게도 점점 데브옵스적인 역량이 요구되면서, 리눅스 서버에 터미널로 접근하게 되는 경우가 많아졌다. 간단하게는 로그나 파일이 존재하는지, 또는 설정파일을 변경하거나 프로세스가 살아있는지 등등 여러 가지 이유에서 말이다. 그럴 때마다 리눅스 터미널 단축키를 구글링 하면서 하곤 했는데, 한동안 안 하면 까먹고 다시 찾아보고... 무한 반복이었다. 이런 일이 잦아지면서, 리눅스를 공부해야겠다고 계획했다. 에디터 조작을 vim 단축키로 통일하는 것은 그 과정 중 하나다. 사실 vim을 사용하는 건 굳이라고 생각을 했었다. 하지만 최근 들어서 에디터를 통일할 필요성을 점점 느끼게 됐다. 회사에서는 윈도우OS에 이클립스와 vscode를 사용하고, 개인적으로는 맥OS에 인텔리제이랑 웹스톰..
중복되는 컴포넌트 컴포넌트 중복이 가장 많은 곳은 프론트영역이다. 달력, 입력박스, 안내창 등은 대부분의 화면에서 공통적인 기능으로 사용된다. 스타일은 물론 로직(이벤트처리)이 같은 컴포넌트도 많을 것이다. 프론트에서 공통 컴포넌트를 개발하고 관리하는 것이 중요하지만, 현재 진행 중인 프로젝트에서는 그러지 못했다. 서버에서 관리하는 컴포넌트의 경우 jsp tag 라이브러리를 이용해 어느정도 관리가 됐지만, 화면에서 관리해야 하는 컴포넌트(Clinent Side Rendering)의 경우 전혀 관리되지 못했다. 똑같은 기능을 하는 컴포넌트들이 각자 개발되다보니, 작은 변경 하나도 모든 화면을 수정해야 했다. 유지보수 지옥이나 다름없었다.😭 사실 이렇게까지 된 이유는 별다른 방법이 없다고 생각했기 때문이다...
널널(null null)하게 개발하지 마세요 언어마다 약간의 차이가 있지만, 자바에서는 존재하지 않는 객체 메모리 주소를 `null`이라 표현한다. 따라서 원시타입을 제외한 객체를 가리키는 모든 변수는, 초기에 null 상태라고 볼 수 있다. null을 참조하려고 하면 자바는 NPE(Null Point Exception)라는 런타임 오류를 뱉어내는데 해결하기 쉬우면서도 어려운 오류다. null safe하게 코드를 작성하려고 노력하지만, 항상 예상하지 못한 곳에서 NPE가 발생한다. 런타임 오류기 때문에 코드가 배포돼서 서비스되기 전까지는 모르기 때문에 치명적이다. 널 레퍼런스를 처음 만든 토니 호어가 '10억 불짜리 실수'(billion dollar mistake)였다고 회고한 적 있다. 널 포인터를 체..
브랜치는 자주 분기하고 커밋 단위는 깔끔하게! 업무 컨텍스트가 바뀌면 브랜치를 분기하고, 작업 후 여러 커밋들을 `squash`해서 유의미한 커밋 메시지 단위를 유지하는 것이 좋다고 생각했다. 실제로 그렇게 했을 때 `revert`하기도 편하고 커밋히스토리도 비교적 깔끔하게 관리되기 때문이다. 하지만 최근에 브랜치 전략을 설명할 일이 생기면서, 다른 회사의 브랜치 전략들을 찾아봤는데 잘못 알고 있던 정보들이 많아 글로 정리한다. 커밋은 적어도 하루에 한 번 유의미한 커밋을 만들어 내는 것은 좋지만, 그것보다 내가 작업한 결과물을 동료들에게 빠르게 공유하는 것이 훨씬 중요하다. 왜냐하면 소스 통합 시 발생하는 충돌(conflict)때문이다. 개인적으로 충돌을 많이 경험하진 못했지만, 발생할 때마다 스트레스..
2023.02.13 - [Backend/Java] - 공통 lib -> spring-boot-starter로 바꾸기(1) 2023.03.20 - [Backend/Java] - 공통 lib -> spring-boot-starter로 바꾸기(2) 조금 다른, 새로운 프로젝트 등장 프로젝트가 커져가면서, 기능을 분리해 새로운 프로젝트로 관리해야 했다. 기존에 공통 기능 프로젝트(master)와 업무 프로젝트(slave)를 잘 분리했기에 손쉽게 프로젝트를 구성할 수 있었다. 각 업무 프로젝트(slave)마다 필요한 설정이 조금씩 다를 것이다. 특별하게 필요한 설정은 각 프로젝트에서 설정해 사용하면 되지만, 문제는 master 프로젝트에서 제공하는 공통 기능이 특정 프로젝트에서는 필요 없는 상황이 생길 수도 있다..
