엔티티클래스에서 질문입니다

우선 해당 데이터베이스와 연결이 제대로 되지 못했을 가능성이 있습니다. 이건 프로젝트 실행시에 에러 메시지가 뜨는지 확인하시면 됩니다. 또 다른 의심은 application.properties의 DDL AUTO 설정과 로그 설정 부분일 듯 합니다.

수정시 writer값이 삭제되는 오류

우선 TodoServiceImpl 코드를 살펴보면 기존의 엔티티를 가져와서 DTO에서 일부분만 수정하는 아래와 같은 방식입니다. @Override public void modify(TodoDTO todoDTO) { Optional result = todoRepository.findById(todoDTO.getTno()); Todo todo = result.orElseThrow(); todo.changeTitle(todoDTO.getTitle()); todo.changeDueDate(todoDTO.getDueDate()); todo.changeComplete(todoDTO.isComplete()); todoRepository.save(todo); }로 되어 있기 때문에 writer 가 변경될 부분은 없어 보입니다만.. 혹시 처리되는 코드가 좀 다른 부분이 있을까요?

교안 31 오타 수정해주세요

아.. 오타가 있었네요.. 감사합니다. 강의자료를 수정해서 다시 업로드했습니다.

쿠키에 accessToken, refreshToken을 담고, 조회 시에 undefined

우선 로그인을 처리해서 리액트에서 받은 결과가 정상적인 객체인지 확인한 후에 JSON.stringify( )를 해 주어야 합니다. 혹시 API서버에서 결과가 다르게 나오는지 확인해 주시고 객체가 아닌 문자열이라면 코드를 확인할 수 있는 링크를 꼭 아래 적어둔 메일로 알려주시면 감사하겠습니다. 로그인을 한 후에 브라우저의 application 항목을 보시면 url인코딩된 문자열이 아래처럼 존재하는지 먼저 확인해 주세요 (package.jso의 react-cookie의 버전도 확인해 주세요) "react-cookie": "^6.1.1", %7B%22social%22%3Afalse%2C%22pw%22%3A%22%242a%2410%24emXZMHr5UuD.oR1XICr3B.318Fs6ml1uHXdXMQ%2FSGCVzBFJ2ojYAq%22%2C%22nickname%22%3A%22USER1%22%2C%22accessToken%22%3A%22eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzb2NpYWwiOmZhbHNlLCJwdyI6IiQyYSQxMCRlbVhaTUhyNVV1RC5vUjFYSUNyM0IuMzE4RnM2bWw. 생략 리액트의 cookieUtil에서는export const getCookie = (name) => { const member = cookies.get(name) console.log("getCookie-------------------------------------") console.log(member) return member } 와 같이 수정해서 쿠키에서 제대로 값이 읽어내는지 확인해 주세요.. (사진)혹시 문자열 생성이 이상하게 되시나요?만일 그렇다면 제가 백엔드 코드를 볼 수 있도록 cookie_00@naver.com으로 알려주세요 정상적인 동작 여부는 해당 섹션의 마지막 수업자료로 서버쪽 소스 코드가 있으니 참고삼아 실행해서 동작시켜 보시는 방법도 있습니다.

소셜 로그인 질문 있습니다

이상하게 댓글이 등록이 안되네요 ㅠㅠ 위험하다고 표현한 이유는 우선 서버에서 지정된 패스워드로 만들어진다면 실제 사용자는 자신의 패스워드를 모르는 상황이 되므로 최대한 빠른 시간내에 자신의 패스워드를 만들어야만 합니다. 만일 공격자가 서버의 패스워드를 알아내면 많은 소셜 로그인 사용자들의 개인 정보가 다 위험해 질 수 있다는 의미입니다.

JWT 설정 후 JSON 데이터가 문자열로 옵니다...

문제는 API서버 쪽인듯 합니다. 조회하는 경우이니 API서버를 브라우저에서 호출했을때 JSON형식으로 반환되는지를 확인해 봐야할 듯 합니다. 컨트롤러에서 객체를 반환하면 기본적으로 JSON으로 변환이 되어서 전송되는 것을 먼저 체크해 보셔야 할것 같네요.. axios를 이용하시니 정상적이면 JSON.parse가 필요하지는 않으실 겁니다.

loginSlice에서 reject가 반환되지 않습니다.

로그인 실패에 대한 질문이시죠? 스프링 시큐리티에서 정상적으로 로그인 자격증명에 실패했다면 ApiLoginFailHandler가 동작하는지 먼저 로그를 찍어서 확인해 주실 필요가 있습니다. 예제의 경우 로그인에 실패시에 HTTP의 상태 코드는 200으로 정상적으로 처리합니다. 다만 메시지의 구성만을 다르게 하고 있습니다. (강의에서는 5.4의 마지막 부분) loginSlice의 rejected의 경우 상태코드가 400대 혹은 500대로 처리되어야만 합니다. 따라서 APILoginFailHandler에서 다른 404상태 코드를 반환하시는 방식을 이용하시거나 응답 메시지내에 error가 있는지를 확인하셔야할 듯 합니다. (개인적으로 4xx 에러 메시지를 반환하지 않은 것은 해당 계정의 존재 여부를 확인할 수 있기 때문에 API 제공 서비스 들이 정상적인 응답 메시지를 사용하는 것이 좀 의아했습니다) 브라우저에서 로그인 실패시에 전송되는 응답 코드를 확인해 보시고.. 응답 메시지도 다시 체크해 보시기 바랍니다. 혹시 문제가 해결이 안되시면 cookie_00@naver.com으로 소스 코드를 볼 수 있는 주소와 함께 메일을 보내주세요

강사님 질문 있습니다.

네.. 말씀하신 내용이 맞습니다. 조금 더 보충설명하자면.. DB에 따라 다르긴 하지만 BLOB, CLOB 처럼 바이너리 데이터나 큰 용량의 텍스트 데이터를 저장하는 타입이 있습니다. 예를 들어 엄청 중요한 정보라면 일반 파일 보다는 보안이 가능한 데이터베이스내에 저장하게 되는데 이런 경우가 이미지를 데이터베이스내에 저장하는 방식이라고 보시면 됩니다. 하지만 DB에 이미지 파일을 저장하면 조회할때 DB에서부터 많은 양의 데이터를 가져오기 때문에 성능이 좋아질 수 없기 때문에 그 정도의 중요한 파일이 아니라면 파일 시스템 등을 이용해서 이미지등을 저장하고 데이터베이스내에는 파일의 식별 값 정도만 보관한다고 생각하시면 됩니다.

delete에 대한 테스트를 진행하지 않는 이유가 뭔가요??

좋은 질문 감사합니다. delete작업에 대해서는 우선은 쿼리 자체가 단순하기 때문에 오류가 날 가능성이 거의 없으니 여러 테이블을 삭제하거나 변경하지 않는 이상 굳이 테스트 코드를 만들지 않는 것이 강의 진행상 나아보였기 때문입니다. 또한 테스트 코드는 빌드 과정에서 실행되기 때문에 가능하면 delete는 실행하지 않는것이 좋기 때문에 작성하지 않은 것입니다.

17강 강의중 문의드립니다.

작성하신 TodoDTO의 tno가 혹시 long(기본자료형)으로 되어 있지 않으신가요? longValue( )를 적용하신걸 보면 그럴꺼 같은데요.. 기본자료형은 0과 같은 기본값이 있기 때문에 엔터프라이즈급 개발에서는 사용하지 않으시는게 좋습니다(물론 기본값이 필요한 경우에는 괜찮습니다만). 제 코드는 TodoDTO의 tno가 객체타입으로 Long으로 잡혀 있을 겁니다.