heemang.dev heemang.dev

@Data 애너테이션포함하는 애너테이션 : @Getter, @Setter, @RequireArgsConstructor, @ToString, @EqualsAndHashCode/** * @see Getter * @see Setter * @see RequiredArgsConstructor * @see ToString * @see EqualsAndHashCode*/@Target({ElementType.TYPE})@Retention(RetentionPolicy.SOURCE)public @interface Data { String staticConstructor() default "";} @Data 애너테이션이 포함하는 애너테이션들에 대해서 알아보자. @Setter는 수정하면 안 되는 값을 수정하게 만든다.E..

문제 시나리오CorsConfig 클래스에 작성된 domain 필드가 존재한다.@Value 애너테이션을 사용하여 application.yml에 작성한 값을 domain 필드에 주입한다.application.yml... 생략server: domain: ${SERVER_DOMAIN}CorsConfig@Configurationpublic class CorsConfig { @Value("${server.domain}") static String domain; public static CorsConfigurationSource corsConfiguration() { CorsConfiguration configuration = new CorsConfiguration(); ..

1. 회고 카드(Section)와 회고 보드(Retrospective)우리 프로젝트는 1개의 회고 보드에 여러 개의 회고 카드를 작성할 수 있다. 즉, 회고 보드와 회고 카드는 1:N 관계이다. 따라서 회고 보드를 조회하면 작성된 모든 회고 카드를 조회할 수 있다. 2. 새로운 회고 카드(Section) 생성하기우리 프로젝트는 회고 보드(retrospective)에 작성된 모든 회고 카드(section)를 DB에서 조회한다. GET /sections를 호출하여 모든 회고 카드를 조회하는 것을 확인할 수 있다. 새로운 회고 카드를 등록하면 POST /sections 요청을 통해 DB에 새로운 회고 카드를 등록한다. 생성된 회고 카드를 포함하는 모든 회고 카드를 가져오기 위해서 다시 GET /section..

1. 사건의 발달도메인을 구매하기 전에는 AWS EC2의 IP를 사용하여 Swagger를 배포하였다. Swagger를 통해 서버로 요청을 보내게 되면, Swagger 주소와 서버 주소가 동일하기 때문에 CORS 문제를 고민할 필요가 없었다. 이젠 도메인을 구매하고 SSL 인증서를 발급받아 도메인 주소로 Swagger를 접속하도록 하였다. 그런데 GET 요청을 제외한 나머지 HTTP 메서드에 대해서 전부다 403 Invalid CORS request 오류가 발생하였다. 도메인에 맞춰서 Cors와 Swagger 설정을 했음에도 해결되지 않았다. 하루 내내 붙잡고 있어도 해결되지 않아, 게임으로 잠시 도피하고…. 다음날 처음부터 차근차근 해보니 해결책을 찾았다. 동일한 개발 환경에서 이 오류가 발생하는 사람이..

1. 내가 기대했던 결과사용자가 Authorization 헤더에 Bearer 타입의 Access Token을 담아서 서버로 요청한다.서버에서 Access Token을 받아서 만료된 토큰인지 검증한다.만료된 토큰이라면 ExpiredJwtException 예외를 발생시킨다.@ExceptionHandler를 사용하여 예외를 핸들링한다.JWT 토큰을 검증하는 FilterdoInternal()에서 사용자의 요청을 가로챈다.HttpServletRequest에서 1-1에서 담은 Access Token을 가져온다.try문에서 parseToken()를 호출한다.validateToken()를 통해 토큰을 검증한다.이때, 토큰이 만료되었는지 확인한다.토큰이 만료되었다면 ExpiredException 예외가 발생한다.try-..

1. 프로젝트 환경Java 17SpringBoot 3.3.2Code Deploy기반 CI/CD 2. Code Deploy는 .bashrc 파일을 사용하지 못한다.CI/CD 파이프라인 구축을 위해 Code Deploy를 사용하였고, 빌드된 파일을 AWS EC2에서 실행하기 위해 .bashrc 파일에 환경변수 값을 등록하였다. EC2의 .bashrc에 환경변수를 등록하였으므로 빌드된 파일을 실행시켰을 때, 문제가 없을 것이라 생각했습니다. Github으로 코드를 push 하면 사진과 같이 문제없이 EC2로 jar 파일이 배포됩니다. AWS EC2의 .bashrc에 prod 환경에서 필요한 환경 변수 값을 저장하였고, 스프링 애플리케이션 실행 시에 사용하기를 기대하였습니다.  그러나… 스프링 애플리케이션 실행..