회원가입 이메일 인증 방법 개선전에는 MemberEntity에 enabled 필드를 추가하여 회원가입시 DB에 가입정보를 insert할때 enabled 필드에 false값을 넣어서 회원을 비활성화 하고 전송된 인증메일에 링크를 누르면 enabled 값을 true로 변경하여 회원을 활성화 시켰다. 하지만 이 방법은 회원이 인증을 하지 않으면 DB에 쓰레기 값만 남게 되고 회원이 다시 똑같은 아이디(email)로 회원가입을 못한다. 그래서 이메일로는 인증번호를 전송하고 회원가입 화면에서 인증번호를 제대로 기입해야 회원가입이 완료되도록 설정하였다. 인증번호 유효성은 Redis를 활용하였다. DB를 사용안하고 Redis를 활용한 이유는 DB에 직접 접근하지 않고 Redis 캐싱을 활용하여 인증을 빨리 할수있고 ..
회원가입 후 스프링 시큐리티의 기능을 활용해 계정을 비활성화하고 이메일 인증을 하여 회원을 활성화하는 방식으로 가장 간단하게 이메일 인증을 구현하였다. 1. mail 의존성 추가. implementation 'org.springframework.boot:spring-boot-starter-mail' 2. 구글 계정 생성 -> 2차 비밀번호 적용 -> 앱 비밀번호 생성.이메일을 막 보내게되면 계정이 정지될 수도 있으니 새로운 계정으로 하는 걸 추천한다. 계정 생성 후 2차 비밀번호를 적용하면 앱 비밀번호를 생성할 수 있는데 이 앱 비밀번호를 이용해서 메일을 전송할 수 있다. 3. application.yml 설정Gmail SMTP 연결을 위한 설정이다. 위에서 생성한 앱 비밀번호를 password칸에..
CI/CD 툴은 대표적으로 젠킨스가 있지만 젠킨스는 별도의 서버가 필요하는 등 설정이 어렵다. 그래서 규모가 작은 프로젝트에 적합하고 빠르게 구축이 가능한 Github Actions를 선택하였다. Github Actions 플로우Github Actions 빌드 배포 플로우는 Github Actions를 작동시켜서 빌드 결과물 jar 파일을 S3에 전송한다. 그리고 S3에 있는 jar파일을 CodeDeploy가 EC2에 배포 해서 실행 시킨다. 위에서 Github Actions가 CI(지속적인 통합) 역할을 하고 CodeDeploy가 CD(지속적인 배포) 역할을 한다.Github Actions는 프로젝트 소스를 빌드및 테스트코드도 실행시켜 배포하기에 적합한 소스인지 확인 한다. 만약 테스트 코드중 하나라..
파라미터 유효성 검증에 대한 코드 리팩토링 과정을 설명한다. 파라미터 유효성 규칙 추가처음에 유효성 검증을 위해 회원가입 컨트롤러에서 CreateMemberRequest DTO를 받아서 회원가입 로직을 처리하고. 앞에 @Validated를 붙이고 DTO 필드에 어노테이션을 이용하여 필드마다 유효성 규칙을 추가하였다. 파라미터에 대한 유효성 검증을 하였다. 위 방식의 문제는 유효성 규칙을 통과 못했을때 응답하는 messgae가 너무 정형화 되지않은 형식으로 된다. 사용자한테 아래 메시지대로 보여주면 이해하지 못하므로 필요한 메시지를 정형화 시켜야 된다. BindingResult 이용해서 파라미터 유효성 에러 메시지 정형화메시지를 정형화 되도록 하기 위해서 첫째로 BindingResult를 쓰는 방법이 있..
자바 11 -> 17업그레이드와 스프링시큐리티 5버전에서 6버전에서 업그레이드 하고나서 발생한 error와 warning을 수정한 과정이다. 업그레이드 하고 나서 security 설정 부분에서 에러가 발생하여 에러를 수정하였다.SecurityConfiguration 수정 cors() 메서드 들어가서 documentation에 들어가서 삭제된 이유를 확인해보니 공식문서에 아래와 같은 이유가 있었다. 단순하게 이해해서 이전 방식(메서드 체이닝)이 가독성이 안좋기도 하고 람다 방식과 메서드 체이닝 방식 같이 사용하기 때문에 혼란을 야기한다는 뜻 같았다. 그래서 메서드 체이닝 방식을 완전히 삭제 한 것 같다. 그래서 아래처럼 메서드 체이닝 방식을 모두 람다식으로 수정하였다. 그리고 cors.disable()..
1차 프로젝트에서 Mybatis를 적용한 아키텍쳐는 단순히 Service에서 MybatisRepository를 의존한 것이다. JPA를 변환하고자 했을때 단순하게 생각하면 아래 아키텍쳐를 가질 수 있다.하지만 위 설계는 DIP를 위반한 것이다. 왜냐면 고수준 Service가 저수준 MybatisRepository와 JpaRepository를 직접 의존하기 때문이다. MybatisRepository를 지우지 않고 JPA 기능을 추가한 이유는 언제든지 수정중인 소스를 운영에 반영할수 있도록 하기 위함이다. JPA기능을 추가하고 테스트코드도 작성되지 않은 상태에서 Mybatis 기능을 삭제해버리면 이 소스를 운영에 반영 할 수 없다. 그래서 언제든지 운영에 반영할 필요가 있을때 빠르게 수정중인 소스에서 Myb..
1차 팀프로젝트에서는 Springboot 2.7, Mybatis, SpringSecurity 5.x 버전을 이용해서 개발을 하고2차 팀프로젝트에서는 1차 프로젝트 레파지토리를 복사하여 Springboot 3.2, Jpa, SpringSecurity 6.x 버전으로 업그레이드 하는걸로 목표 삼았다. 1차 팀프로젝트를 버전 업그레이드와 1차에서 못한 기능들을 개발하고 1차에서는 지키지 못한 Solid 설계 원칙을 지켜 적용시키기로 하였다. 1차 팀프로젝트에서는 문서관리를 Jira, Github, Notion, Google Docs 4개 툴에서 관리하여 스프린트를 잘 지키지 못하여서 이번에는 Github 하나의 툴에서 관리하도록 하였다.1차 팀프로젝트 문서관리 정리 링크 : https://deftkang.ti..