아장아장거리면서 주책부리는 블로그

일단 클래스를 만들었다. @SpringBootTest는 이 테스트가 스프링 부트 상에서 돌아간 다는 것을 의미하고, @Transactional은 해당 클래스가 트랜잭션을 만듦을 의미한다. 일단 C, R, U, D를 다 테스트해보아야 하는데, 생각해보면, 만든게 조회가 제대로 되면, 내 머리같이(?) 비어있는 데이터베이스에 데이터가 생기는 것이다. 즉, 생성은 테스트하지 말고, 그냥 생성시키는 로직을 만든 뒤, 조회를 시키면 되는 것! 그래서! @Autowired private MemberRepository memberRepository; @Autowired private EntityManager em; @BeforeEach public void initData(){ RegisterRequestDto re..

사실 게시판 만들기를 하다가 대략 2~3주 정도를 쉰 것 같다. 이유인 즉슨, 리포지토리를 테스트하는 방법을 찾다가 여러 강의들을 찾게되었다. 공부하다가 로드맵? 이라는 게 있었다. 로드맵을 보니까 또 이게 다 뭔지 알고싶었다 (또 호기심이 미쳐 날뛰어 버렸다) 그래서 이제 할 수 있겠냐고? ㅆㄱㄴ 가능하니까 이제 다음 과정들을 써보려고 한다. 일단 리포지토리의 기본적인 기능들을 만들어볼 생각이다. 우리가 백엔드 프로그래밍을 배우면 기본적으로 CRUD라는 것을 듣게 된다. Create Read Update Delete 이렇게 4가지가 존재한다. 이에 대한 기능들을 Spring Data JPA에서 지원하는 리포지토리를 이용해 만들어보려고 한다. package com.board.Board_Upgraded.r..

Member라는 엔티티에서 이루어지는 도메인 로직에 대한 테스트들을 만들었다. 이 테스트를 정상적으로 수행하기 위한 코드를 만들어보아야 겠다. Member라는 도메인 로직을 짜면서 추가적으로 고민했던 부분은, 다른 도메인과 엮여 사용되어 다른 도메인, 다른 기능에 종속적이지 않게 하려고 했다. 외부에서 Member에 대한 데이터를 변경하는 기능을 수행하는 경우를 만들지 않도록, 도메인 내에서 모든 로직을 만들려고 했다. 이러한 점을 토대로, 회원가입 / 정보 수정 / 비밀번호 변경 기간 만기여부 확인의 기능을 만들었다. 회원가입 일단 회원가입 로직부터 정리를 해보았다. 일단 필요한 경우는 이메일 형식이 올바르지 않으면 예외처리 비밀번호 2번 입력이 서로 일치하지 않으면 예외처리 예외가 없다면 인스턴스 초..

Member에 대한 테스트를 만들어보아야 겠다. 일단, Member 생성자에 RegisterRequestDto를 넣을 것이다. 그러기 위해, 테스트를 위한 RegisterRequestDto를 생성하주자. private RegisterRequestDto makeTestRegister(){ return new RegisterRequestDto("username", "nickname", "email@email.com" , "password", "password"); } AllArgsConstructor로 모든 인스턴스를 넣은 Dto를 만들었다. 이를 @Builder를 이용해 조금 더 깔끔하게 만들어보았다. @AllArgsConstructor @Data @Builder public class RegisterRe..

이전에 멤버에 대한 구상을 해둔 상태이다. 이에 맞는 멤버를 만들어보아야 겠다. @Entity @Data @AllArgsConstructor @NoArgsConstructor @Builder public class Member extends BaseEntity { @Column(name = "MEMBER_USERNAME") private String username; @Column(name = "MEMBER_NICKNAME") private String nickname; @Column(name = "MEMBER_EMAIL") private String email; @Column(name = "MEMBER_PASSWORD") private String password; @Column(name = "MEMB..

기본적인 설정들은 어느정도 만들어두었다. 모든 로직들을 만들고, 이에 대한 테스트 및 정리들을 해볼까 한다. 일단 회원부터 가지고 있어야 할 인스턴스들과, 로직들을 생각해봐야 한다. 회원 엔티티 인스턴스들 아이디(username) 닉네임(nickname) 이메일 비밀번호 역할 가입일자(BaseTimeEntity에 추가된다) 최근 수정일자(BaseTimeEntity에 추가된다. 수정일자가 1달이 넘으면 비밀번호 변경 요청을 보낸다) 기능 회원가입 로그인 닉네임 수정 비밀번호 수정 이메일 수정 비밀번호 변경 요청여부 확인 이러한 기능들을, 데이터베이스를 사용하지 않고 Member라는 도메인에서 사용할 수 있는 로직들로 어떤 부분들이 필요할지 생각해보아야 한다. 최소단위의 기능 회원정보를 가져오면 Member..

모든 엔티티에 공통적으로 쓰이는 부분들을 만들어두어야겠다. 일단, 기본적으로 데이터베이스에 들어가기 위해서는 모든 테이블에 id라는 속성이 존재한다. 또한, 생성일자, 수정일자를 등록해서 사용하려고 한다. 생성, 수정일자의 경우에는 사용자 : 비밀번호 최종 수정일자를 확인해, 수정일자를 기준으로 일정 기간이 지나면 비밀번호 재설정을 요청하는 알림을 추가한다. 게시물 : 게시물 작성일자를 추가하고, 수정되었을 경우, 수정됨을 알릴 수 있다. 댓글 : 게시물과 마찬가지로 작성일자, 수정일자를 추가한다. 메시지 : 카톡과 마찬가지로, 보내진 시간등을 설정해둘 수 있다. 이렇게 다양하게 쓰이기 때문에, BaseEntity로 설정해, 모든 엔티티에서 추가적으로 id, createdTime, updatedTime을..

일단, 필터를 만들어서 우리가 해야할 일을 알아야 한다. 토큰을 받아왔을 때, "Authorization"으로 되어있는 헤더를 가져온다. 이 헤더에 대한 인증 방식이 우리의 토큰과 같을 경우, 토큰 부분을 떼고 나머지를 가져온다. 이 부분이 사용 가능한 토큰인 경우, 사용자의 인증정보를 Authentication에 담아주면 된다. 이러한 동작을 필터에서 만들어주면 된다. 일단, 토큰을 받아왔을 때 필요한 부분만을 가져와주는 동작을 만들었다. private String resolveToken(HttpServletRequest request) { String bearerToken = request.getHeader(AUTHORIZATION_HEADER); if (StringUtils.hasText(beare..

Token Provider에서 토큰의 서명, 토큰 자체의 문제에 대한 예외를 처리하거나, 토큰의 지원여부와 만료여부에 대한 예외도 처리했다. 그런데도 처리해야할게 남았다. 뭘까...? 생각해보면,우리가 보낸 예외처리에 대해 어떻게 반응해야 할지 처리를 안했다. 이전에 만들었던 validateToken부분에서는 모든 예외를 받아와 이를 로그로 출력시키는 과정을 만들어두었다. 그렇다면, 사용자에게 해당 예외에 대해 어떻게 처리할지 알아야 한다. (AuthenticationEntryPoint) 또한, 이 때는 토큰에 문제가 있을 경우에만 처리가 되었으며, 토큰에 문제가 없는데 토큰에 있는 사용자의 권한상 해당 요청을 할 수 없을 경우 이를 처리해주어야 한다. (예를 들면, 사용자가 관리자 페이지를 가면 곤란해..

이전에 정리해두었던 TokenProvider의 기능들을 정리해보려고 한다. 일단 생성자! public TokenProvider(@Value("${jwt.secret}") String secretKey) { byte[] keyBytes = Decoders.BASE64.decode(secretKey); this.key = Keys.hmacShaKeyFor(keyBytes); } @Value에서 jwt.secret는 application.yml에서 가져오는 것이다. jwt: secret: 이런식으로 되어있을 때, secret: 뒤에 사용할 키를 적으면 된다. 이전 페이지에서 정리를 간단히 했던 것 같은데, 그게 전부라 설명은 스킵! public TokenDto generateTokenDto(Authentica..