개발 일기

상황 비밀번호 암호화를 구현하는 기술을 고민하고 있었습니다. 해시를 적용하고자 했으나, 해시는 같은 입력 값에 대해, 항상 같은 결과 다이제스트가 나오는 취약점이 있습니다. 문제 위의 취약점 때문에, 해시 알고리즘은 레인보우 테이블을 사용해서 해킹 당할 위험이 있었습니다. 해결/결과 솔트는 해싱 하기 전에, 랜덤 문자열을 비밀번호에 더합니다. 솔트와 함께 암호화 하면, 솔트가 임의 값이기 때문에 원래 값을 찾아내기 어렵습니다. 즉, 사용자 별로 다른 솔트를 사용한다면, 동일한 패스워드를 사용하더라도 다이제스트가 다르게 생성됩니다. 자바에서 지원하는 BCrypt 라이브러리를 사용하여 솔트를 구현했습니다. 해시와 비교할 때, 결과값이 예측 불가능하기 때문에, 보안을 강화하는 이점을 얻을 수 있었습니다.

상황 인증 기능을 구현할 때, 로그인이 필요한 API에 인증 처리를 강제해야 했습니다. 기존 코드는 인터셉터의 addPathPatterns로 모든 경로를 더하고, excludePathPatterns로 일부 경로만 제외하여 구현했습니다. 문제 위의 방식은 로그인이 필요 없는 경로를 추가할 때마다 직접 입력해줘서, 오타가 발생할 위험이 있었습니다. 이러한 위험을 줄이면서, 컨트롤러에서 로그인 필요 여부를 명시적으로 표현하는 방법을 고민하였습니다. 해결 /결과 @LoginCheck 라는 커스텀 애노테이션을 만들었습니다. Retention Policy를 설정하여, 런타임까지 객체를 유지 했습니다. 메서드 단위로 적용함으로써, 인터셉터를 거쳐갈 때 @LoginCheck가 붙은 메서드는 로그인 여부를 확인하도록 강..

인증/인가 기능 구현 로그인/회원가입/메인 화면을 제외하고는 인증과 인가 과정을 거쳐야 합니다. 여기서 인가는 사용자의 권한을 확인하는 작업이며, 인증은 사용자의 신원을 확인하는 작업입니다 (서버가 갖고 있는 회원 정보와 일치하는지, 즉 가입 회원이 맞는지). 유저가 상품을 주문하는 상황을 가정해봅시다. 서비스는 유저의 주문이라는 행위를 기록하기 위해, 인증을 필요로 할 것입니다. 제가 만들고 있는 서비스는 판매자만 상품을 등록할 수 있습니다. 더불어, 등록한 상품은 해당 상품을 등록한 판매자만 수정할 수 있습니다. 이 과정에서 판매자의 권한을 확인해야 합니다. 그러면 판매자는 제품을 등록하고, 수정하고, 재고를 변경할 때마다, 로그인을 해야할까요? API 를 이동할 때마다 로그인을 한다면 너무 번거롭겠..

GC (Garbage Collection) 란? 가비지는 프로그램에서 객체를 할당했지만, 더 이상 참조되지 않는 객체입니다. 가비지들을 제거하는 작업을 가비지 컬렉션(Garbage Collection, 이하 GC) 이라고 해요. 하나의 객체는 메모리를 점유하기 때문에, 쓰지 않는 객체는 메모리 최적화를 위해 해제해주는 거죠. C언어에도 GC라는 개념이 있습니다. C언어에서는 GC 작업을 개발자가 하는 반면, 자바에서는 JVM 이 메모리 관리를 도맡아 해줘서 개발자가 편합니다. GC 의 이점? 위의 설명에서 추측할 수 있듯, 메모리 최적화가 됩니다. 그리고 GC 를 많이 할 수록, 서버의 응답시간에 영향을 미치기 때문에 성능 관리에 있어서도 중요합니다. 특히 Full GC 의 경우 속도가 매우 느립니다 (..