토큰을 저장하는 위치토큰은 일반적으로 쿠키, 스토리지, 로컬 변수 등에 저장한다.쿠키는 HttpOnly를 true로 주게되면 script로 접근이 불가능하기 때문에 스크립트를 실행하는 XSS를 방지할 수 있지만, 모든 HTTP 요청에 자동으로 포함되기 때문에 요청을 위조하는 CSRF 공격으로부터 안전하지 않다.따라서 Secure 옵션으로 https에서만 전송하도록 설정하고, sameSite 설정을 통해 cross site  전송을 막아야한다. 반면 스토리지는 HTTP 요청에 자동으로 포함되지 않기 때문에 CSRF를 방지할 수 있지만, script로 접근할 수 있다. 위와 같은 이유로 액세스 토큰을 함수 스코프 내에서만 동작하는 로컬 변수에 저장하는 것이 가장 안전하다. 액세스 토큰을 발급받는 용도 외에는..

폐쇄망 환경에서 서버 이중화 구현하기군 부대, 병원, 경찰, 소방, 금율 등의 보안이 중요한 환경은 내부에서만 접근할 수 있도록 페쇄망 환경에서 서버를 운영하는 경우가 많다. 목표는 인터넷 연결이 되지 않는 폐쇠망 환경에서 Apache(Web Server)와 Tomcat(WAS)를 분리해서 배포하고 WAS 서버를 이중화 하여 1번 WAS가 다운되더라도 2번 WAS가 이어서 작업을 수행할 수 있도록 서버 환경을 구성하는 것이다. 이를 위해서 필요한 것은 Apache가 Tomcat에게 요청을 고르게 분배할 수 있도록 LoadBalancer 역할을 할 수 있어야하며, 한쪽 Tomcat이 다운됐을 때 세션 정보를 유지하기 위해서 Session Clustering을 구현해야한다. 또한 웹 서버가 정적 파일에 대한..

개발을 하는 도중 Controller에서 데이터를 주고 받을 때, 각 요청 별 DTO를 다 만드는 것이 좋을까? 아니면 객체를 많이 만들 필요없이 Map을 사용하는 것이 더 좋을까?에 대한 고민이 생겨 찾아본 내용을 정리할려고 한다. Map장점요청에 대해서 별도의 클래스를 만들 필요가 없어서, 관리할 클래스 파일이 줄어든다.받아야될 데이터가 수정되더라도 클래스를 수정할 필요 없이 간단하게 변경할 수 있다.클래스를 만들 필요가 없으니 초기에는 작업 시간이 단축된다.단점요청 데이터의 정합성을 검증하기 힘들다.내부 코드를 읽어봐야 어떤 데이터를 주고 받는지 알 수 있다.검증 로직의 위치가 애매해진다.별도의 타입 캐스팅 로직이 추가된다. DTO장점클래스 명으로 더 명확하게 객체의 역할을 표현할 수 있다.어떤 데..

세션 불일치 문제란?단일 서버에서 세션에 대한 요청을 처리는 문제가 되지않지만, 다중 서버 환경이라면 이야기가 다르다. 인증 정보 세션을 예시로 든다면 유저A는 A서버에서 로그인을 진행했고, 유저B는 B서버에서 로그인을 진행했을 때아무런 설정 없이 두 대의 서버를 운영 중이라면 유저의 요청을 어떤 서버에서 받을 지 알 수 없다.만약 유저A가 B서버에 인증 정보를 요구하는 요청을 보냈다면? B서버에는 유저A의 인증 정보가 없어서 실패 응답을 받을 것이다.즉, 요청이 어떤 서버로 들어가냐에 따라 결과가 랜덤하다는 뜻이다.  해결 방법Sticky Session서버가 여러 대인 경우는 로드 밸런서에서 모든 클라이언트의 요청을 받고 요청을 서버로 넘겨주게된다.이때 로드 밸런서에서 유저A의 요청은 A서버로만 보낸다..