교재 576페이지 : S3의 버킷을 AWS에서 찾을 수가 없음

우선은 버킷에 있는 파일이 조회가 되는지를 먼저 확인해 보시는 것도 괜찮은 방법입니다. 물론 버킷의 이름을 찾으시는게 제일 좋구요 테스트 코드가 실행되었다면 아래와 같이 버킷에서 바로 확인이 되셔야 합니다(아래 그림에서 M14.jpeg파일이 테스트 코드를 통해서 업로드한 파일입니다.).(사진)

질문입니다.

강의 중에도 말씀드렸지만 Querydsl은 버전에 예민하고 변경이 잦아서 섹션 전체가 아니라 해당 강의의 수업자료에 첨부되어 있습니다. (사진) 아.. writer가 수정될 수 없어서 추가할 필요가 없다는 것을 말씀하시는 거 같습니다. 현재 예제에서는 writer는 전달될 필요가 없습니다만.. 나중에 인증 처리가 있다면 Todo의 작성자와 현재 사용자를 비교할 필요가 있어서 제가 넣어둔 것으로 기억합니다. 현재 실습에서도 없어도 될 듯 하네요..에고..

JWTUtil 에 심각한 버그 존재?

말씀하신 내용 중에 좀 이상하다고 생각되었던 부분이 -- 최초에는 accessToken 10분 제대로 할당됨.-- refreshToken 으로 new accessToken 이 1일 단위로 할당되는 현상이었음. 라고 하셔서 그럼 처음 로그인했을때 만들어진 엑세스 토큰도 1일 단위가 되어야 하는데.. 라고 생각했습니다. 그래서 좀 더 코드를 살펴보니 예제 코드에 있는 부분에서 .claims( )위치가 다르네요.. 강의에 파일로 제공된 코드는.. 마지막에 claims( )를 했습니다. .issuedAt(Date.from(ZonedDateTime.now().toInstant())) .expiration((Date.from(ZonedDateTime.now() .plusMinutes(min).toInstant()))).claims(valueMap) 이렇게 되면 valueMap의 iat와 exp가 영향을 주게 되는 것을 확인했습니다(새로 발행된 값 대신에 덮어쓰는 현상이 ㅠㅠ) 이 문제 때문에 RefreshToken의 exp값이 새로 발행된 Access Token의 exp값이 되었던 것 같습니다. claims( )를 한 후에 issueAt( )과 expiration( )이 실행되어야 합니다. .claims(valueMap) .issuedAt(Date.from(ZonedDateTime.now().toInstant())) .expiration((Date.from(ZonedDateTime.now() .plusMinutes(min).toInstant()))) 꼼꼼하게 살펴보지 못한 제 불찰입니다. 죄송합니다.

JWTUtil 에 심각한 버그 존재?

현재 강의 섹션의 마지막에 있는 예제코드를 다시 확인해 보았습니다. Access Token은 10분Refresh Token은 하루 뒤로 정상적으로 생성되고 있는 것을 확인하였습니다(마찬가지로 정상적으로 갱신되는 것도 확인했습니다.). 리액트를 갱신하면서 부트 쪽은 라이브러리의 버전들만 업데이트가 시키고 큰 내용에는 차이가 없긴 합니다만.. 혹시 그 문제일지도 모르겠습니다. 질문 올려주신 코드는 JJWT 0.11.X 버전에 맞는 코드입니다. JJWT0.12.x 버전에서는 (현재 섹션 마지막의 코드 버전) 약간의 차이가 있긴 합니다. return Jwts.builder() .header() // 헤더 DSL 시작 .add("typ", "JWT") .add("alg", "HS256") // 보통 생략 가능 .and() // 헤더 DSL 종료 .issuedAt(Date.from(ZonedDateTime.now().toInstant())) // 발급 시간 .expiration(Date.from(ZonedDateTime.now().plusMinutes(min).toInstant())) // 만료 시간 .claims(valueMap) // 클레임 설정 .signWith(key) // 서명 .build() // Jwt 객체 생성 .compact(); // 문자열로 변환

질문있습니다.

죄송합니다. 기존 강의를 대체하기 위해서 새로 작성하다 보니 기존 코드를 저 역시 유지하고 있지 않습니다. 이번에 새로 강의를 제작한 이유도 기존 소스코드의 제작 버전이 너무 낮아져서 문제가 발생해서 이를 보완하기 위해서였습니다.

스프링부트 부분은 리뉴얼되진 않은건가요?

리액트는 큰 차이가 없어서 동영상은 그대로이고 각 섹션의 소스부분은 3.4.4버전으로 된 코드 입니다

조회기능시 backend 통신 실패

많은 분들이 GPT에서 알려주는 방법대로 하시는데.. ㅜㅜ 이상하게 이 부분이 버전을 좀 타네요.. 우선 시큐리티가 추가되는 부분은 조금 뒤쪽인데 미리 추가하셨나 봅니다. 그렇다면 시큐리티 설정이 문제가 될 수 있습니다. 조금 뒤쪽 섹션에 보시면 인증 처리 부분이 있으실 겁니다. 해당 섹션 마지막에 항상 수업자료로 프로젝트 코드가 있으니 확인해 보시기 바랍니다. 우선 ServletConfig에서는 CORS 관련 설정은 없애 주시고.. package org.zerock.mallapi.config;import org.springframework.context.annotation.Configuration;import org.springframework.format.FormatterRegistry;import org.springframework.web.servlet.config.annotation.CorsRegistry;import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;import org.zerock.mallapi.controller.formatter.LocalDateFormatter;@Configurationpublic class CustomServletConfig implements WebMvcConfigurer{@Overridepublic void addFormatters(FormatterRegistry registry) { registry.addFormatter(new LocalDateFormatter());}// @Override// public void addCorsMappings(CorsRegistry registry) {// registry.addMapping("/**")// .allowedOrigins("*")// .allowedMethods("HEAD", "GET", "POST", "PUT", "DELETE", "OPTIONS")// .maxAge(300)// .allowedHeaders("Authorization", "Cache-Control", "Content-Type");// }} SecurityConfig에서는 다음과 같이 작성해 보세요. http.cors(httpSecurityCorsConfigurer -> {httpSecurityCorsConfigurer.configurationSource(corsConfigurationSource());});http.sessionManagement(sessionConfig -> sessionConfig.sessionCreationPolicy(SessionCreationPolicy.STATELESS));http.csrf(config -> config.disable()); @Beanpublic CorsConfigurationSource corsConfigurationSource() {CorsConfiguration configuration = new CorsConfiguration();configuration.setAllowedOriginPatterns(Arrays.asList("*"));configuration.setAllowedMethods(Arrays.asList("HEAD", "GET", "POST", "PUT", "DELETE"));configuration.setAllowedHeaders(Arrays.asList("Authorization", "Cache-Control", "Content-Type"));configuration.setAllowCredentials(true);UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();source.registerCorsConfiguration("/**", configuration);return source;}

@AuthenticationPrincipal

네 맞습니다 다양한 정보를 처리하기 위해서 MemberDTO타입으로 직접 처리한 것입니다

첨부파일 트랜잭션

말씀하신대로 서비스 쪽에서는 트랜잭션으로 처리되어서 문제가 발생하면 롤백되겠지만 파일 시스템쪽은 그렇지 않습니다. 이를 제대로 처리하려면 우선 서비스에서 예외를 던지게 설계하고 컨트롤러에서 예외가 발생했을 경우에는 업로드된 파일들을 삭제하시는 방법이 가장 깔끔할 것입니다. 아니면 서비스쪽에서 리턴 값을 주고 컨트롤러에서 원하는 리턴값이 안나오는 경우에 업로드된 파일들을 삭제하는 방법도 고려해 볼 수 있을 듯 하네요.. 이와는 별개로 스케줄러를 이용해서 데이터베이스에 없는 파일들을 주기적으로 삭제하는 방법도 나쁘지 않습니다.

6분23초 MainPage 코드와 자료 코드 불일치 관련 문

아.. 혼란을 드려서 죄송합니다. 특별히 권장하는 것은 없습니다. 명시적으로 작성한다면 함수형이 좀 더 알아보기 낫다고 생각하긴 합니다만.. 클라이언트 쪽이라 전혀 차이는 없습니다. 동영상은 계속 이어서 제작되었기 때문에 동영상의 소스 코드를 참고하시는게 좀 더 에러 잡기가 편하지 않을까 합니다.