1. 목표 로그인에 실패했을 때 권한이 없을 때 구체적인 예외처리 ex) "수정 권한이 없습니다.", "삭제 권한이 없습니다.", "로그인 후 이용할 수 있습니다." 공통 처리(코드 중복 제거를 통한 가독성 향상) 2. @PreAuthorize()의 한계 PreAuthorize() 는 로그인 여부나 권한체킹하는 것을 도와줍니다. success or fail로 동작하며 인증/인가 실패 시AccessDeniedException을 반환합니다. 여기서 문제점은 실패의 원인이 로그인을 안해서인지 권한이 없어서인지 등을 구분하기 어렵고 따로 구체적인 예외처리가 불가능합니다. 권한 체킹을 할 때 preAuthorize로 Role에 대해서 체크할 수 있지만 자신의 게시글인지와 같은 추가적인 권한 검증이 필요할 수 있습..
전체 글
정합성을 보장 받는 방법 이미지Url을 DB에 저장하고 S3에 업로드 하는 과정을 어떻게 하면 동기화 할 수 있을까요?? 제가 선택한 첫 방법은Transactional로 묶고 DB저장 -> S3업로드 순서로 진행하는 것입니다. 이렇게 하면 DB에 저장하는 로직이 실패하던 S3업로드 로직이 실패하던 롤백됩니다. (반대의 경우라면 S3는 저장되었는데 DB저장에 실패해 롤백될 수 있음) 문제점 그러나 같은 트랜잭션 내에 묶어버리면 DB 커넥션을 오래 점유하면서 자원이 낭비가 될 수 있습니다. -> S3의 문제로 인해 업로드가 지연되거나 용량이 너무 클 때 등 다양한 이유 트랜잭션 분리 위 방법에서 트랜잭션이 묶여있기 때문에 커넥션 점유 문제가 생겼으니 트랜잭션을 분리해봤지만 아래와 같은 문제점들이 발생했습니다..
정리 1. AccessToken이 탈취될 위험성이 있기 때문에 만료기간 줄임 -> 유지시간 짧아짐(사용자 편의성 낮아짐) 2. RefreshToken도입 -> 유지시간보완 3. RefreshToken 또한 탈취될 가능성이 존재 -> RTR(Refresh Token Rotate)를 이용한 탈취 감지 RTR을 구현하는데에 두 가지 방식이 있지만 저는 확장성을 위해 RT : PK방식을 선택했습니다. 탈취 감지를 해서 처리를 하더라도 완벽한 보안은 불가능합니다. 다만 예방할 수 있는 부분은 최대한 고려하자는 취지에서 고민해보았습니다. PK : RefreshToken방식 RefreshToken : PK방식 장점 - 사용자의 로그인 정보가 하나임을 보장함 -> RT만 만료시킨다면 모든 토큰을 무효화할 수 있음 - ..