
https://heethehope.tistory.com/186 [스프링부트] 스프링 시큐리티의 구조와 처리 과정 / 로그인은 어떻게 이루어질까? 프로젝트에서 로그인을 맡게 되었다. 이를 구현하는 과정 중에 시큐리티를 우선 이해하고 구현하는 것이 좋을 것 같아 코드를 파보게 되었다. 🧙🏻 시큐리티의 동작 순서 우선 자세한 설명에 heethehope.tistory.com 이전 글에 작성한 것을 토대로 시큐리티를 이해하고 로그인을 구현하기 시작했다. 우선, 내가 참여한 프로젝트에서는 로그인에 성공할시, jwt 액세스 토큰을 발급해주기로 했다. 이 글은 프로젝트 구현이 끝난 뒤에 작성되었기 때문에 현재의 코드와 일부 상이하며 그에 따른 오류가 존재할 가능성이 있다. 따라서 따라 치면서 참고할 만한 코드는 아닌 ..

현재 진행하고 있는 프로젝트에서 리프레시 토큰은 쿠키에, 액세스 토큰은 헤더에 담아서 통신을 하기로 했다. 얼마 전, 리프레시 토큰 구현을 마치고 로그인 시, 쿠키를 함께 반환하도록 기능을 구현했다. 그러나 이 과정에서 예상치 못한 오류들이 나왔다. 🍪 수정 전 쿠키 관련 세팅 private Cookie createCookie(TokenResponseDto tokenResponseDto) throws UnsupportedEncodingException { Cookie cookie = new Cookie(JwtTokenProvider.REFRESH_TOKEN_HEADER_STRING, tokenResponseDto.getRefreshToken()); cookie.setMaxAge(Math.toIntExac..

프로젝트에서 로그인을 맡게 되었다. 이를 구현하는 과정 중에 시큐리티를 우선 이해하고 구현하는 것이 좋을 것 같아 코드를 파보게 되었다. 🧙🏻 시큐리티의 동작 순서 우선 자세한 설명에 들어가기에 앞서, 간략한 순서에 대해서 설명하고자 한다. 전체적인 구조의 흐름을 익히는 것이기에 간략하게만 설명하겠다. 첫번째로, 사용자가 로그인을 시도하면 AuthenticationFilter 가 UsernamePasswordAuthenticationToken을 만들고 실질적인 인증 로직을 담당하는 providers 를 관리하는 AuthenticationManager 를 호출한다. AuthenticationManager는 적절한 Provider 를 호출하여 인증 로직을 수행하고 인증된다면 SecurityContextHol..

컨트롤러에서 습관적으로 항상 아래와 같은 방식으로 ResponseEntity 객체를 새로 생성해주고 반환해줬었다. 그러나 문득 이럴 필요성이 있을까 하는 의문이 들었다. 매번 같은 엔티티를 생성하게 되면 메모리 측면에서 낭비가 발생할 것이라고 생각했다. 따라서 이를 개선하고자 했다. 또한, 미리 생성해둔다면 속도 측면에서도 향상될 것을 기대할 수 있었다. return ResponseEntity.status(HttpStatus.OK).body("OK"); 참고한 방식은 아래의 깃헙이다. https://github.com/f-lab-edu/make-delivery/blob/75aff9c6fdcb049e9eccca9e979fa9f8c6cef57f/src/main/java/com/flab/makedel/util..

비동기처리를 구현하면서 taskRejectedException 이 있다는 것을 알게 되었고, thread pool size 를 초과할만큼의 요청이 들어왔을 때의 대처도 필요하다고 생각하게 되었다. 또한, 비동기 처리시에 발생한 오류 역시도 핸들링해줘야하지 않을까 하는 의문이 들었다. 따라서 비동기 처리를 개선해야 한다고 생각하게 되었다. 1. 비동기 처리시 발생한 오류 처리하기 @Component @RequiredArgsConstructor public class AsyncExceptionHandler implements AsyncUncaughtExceptionHandler { private final Logger logger = LoggerFactory.getLogger(getClass()); @Ove..

👻 참고 링크 https://gimmesome.tistory.com/204 [스프링] batch + scheduler로 주기적인 파일 삭제 구현 Spring에서 batch 와 scheduler를 사용하여 매일 같은시각에 업데이트된 시각이 일주일 이전인 파일을 서버와 DB에서 삭제하는 기능을 구현하였다. 1. batch, scheduler 개념 더보기 batch 란? 배치작업은 데 gimmesome.tistory.com https://ecsimsw.tistory.com/entry/Scheduler-%EC%A0%81%EC%9A%A9-%EB%B0%B0%EA%B2%BD%EA%B3%BC-%EA%B5%AC%EC%A1%B0-Spring-Scheduler Scheduler 적용 배경 / Spring Scheduler ..

👻 참고 링크 https://ahndy84.tistory.com/18 [spring boot batch] 1. 간단한 대용량 배치처리, 스프링부트배치 대략 10만 명의 회원을 거느리는 웹서비스를 운영한다고 가정했을 때 우린 매일마다 회원들의 상태변화를 감지하고 운용할 수 있어야 합니다. 가령 오늘까지 우리 서비스에 접속하지 않은지 1년 ahndy84.tistory.com https://khj93.tistory.com/entry/Spring-Batch%EB%9E%80-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B3%A0-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0 Spring Batch란? 이해하고 사용하기(예제소스 포함) 들어가기 앞서.. Spring Batch에는 굉장..
👻 스프링의 Web Layer 아키텍처 디자인 설계의 원칙 - SoC (Seperation of Concerns) 관심사 분리 - KISS (Keep It Simple Stupid) 간단하고 알기 쉽게 어디서 처리해야 할지 결정하고 간단하고 알기 쉽게 만들어야 함 웹 어플리케이션의 관심 사항 1. 사용자 입력 처리 / 올바른 응답 반환 2. 예외처리로 용이한 에러메시지 제공 3. 트랜잭션 관리 전략 4. 인증 / 인가 5. 비지니스 로직 구현 6. 데이터 스토리지 및 기타 외부 리소스와의 통신 스프링부트의 3개의 Layer 1. Web Layer - 최상단에 위치 - 외부 요청을 처리 / 올바른 응답을 반환 - 다른 레이어의 예외 처리 - 인증 관리 / 인가 확인 - 데이터 전송 객체만 처리해야 함 ex..