2023.08.30.수.TIL

• 할 것
  • 9시 각자 기능 구현한 것(좋아요 기능) 머지
  • 10시 튜터님 방문
  • 오후 테스트 코드 설명 듣기
  • mvp 기능 구현 확인
  • 프론트엔드 시작…?
• 9시 각자 기능 구현한 것(좋아요 기능) 머지
  • 팀장님이 머지
  • 새로운 기능
    • 비밀번호 수정 기능 - 변경 기록 3회 이내의 동일한 비밀번호로 변경 불가 옵션
• 10시 튜터님 피드백
  • 게시글, 댓글, 팔로우… 의 api를 어떻게 보여줄지?
    → 각각 동떨어져 있고 어디에서 어떻게 보여주는지 api가 명확하지 않음
    → 각각 기능의 api가 어떻게, 어디서 이어져서? 연관돼서? 보여줄지?

    ```java
    ㅇㅅㄱ (스프링 튜터)
    10:52 AM
    - 위와 같은 이유로 댓글관련 api 명세는 다음과 같이 바뀌어야 할 것 같네요. /api/posts/{postId}/comments/{commentId} . 댓글이 게시글에 대한 댓글만 있는게 아니라서
    ```
    
    ```java
    Comment api가 명확하지 않고
    떨어져 있다고 하던데 (Post, Comment, Follow 등 포함)
    제가 한 댓글 같은 경우는 그럼
    게시글아이디/댓글아이디
    이렇게 표기하고
    이런 수정을 말씀해주신건가요?
    
    단건조회 다건조회가 지금 필요한건 아닌건 아는데
    게시글 들어가면 확인이 되니까
    근데 이걸 프로필 목록 확인 할 때 가져와서 해야할 수도 있을 것 같아서
    미리 만들어놓은거고...
    안쓰면 삭제해도 된다고
    생각하고 있었거든요
    프로필 목록이 내가 쓴 글, 댓글을 보여주는 목록?! -> 네!
    근데 프로필에서
    어떻게 사용할지도 아직 모르는 상태고
    거기에서
    뭐든 응용할 수 있게끔~
    없는 것 보단 나으니까
    만들어놓은거여서...
    그것 때문에 애매하다면
    삭제해도 되는 부분이에요!
    ```

  • 페이징 처리 종류 크게 2가지

    커서페이지네이션, offset/limit 페이지네이션

• 팀장님 피드백
  • 좋아요에서 토큰체크는 유저임플에서 하고 있는 기능이기 때문에 토큰체크 기능 빠져도 됨
  • deleteLikeComment 메서드가 필요하지 않고 Like 메서드 한 개로!!
    • 좋아요, 좋아요 취소 메서드 총 2개가 있어도 프론트에서 한 개의 버튼으로 좋아요 기능을 구현 할 수 있긴 하다!! 하지만 프론트엔드에서 코드가 길어지고 백엔드에서 무거워지는 단점! 그래서 굳이 2개를 쓰지 않아도 된다
    • Like 메서드 안에서 좋아요와 좋아요 취소가 구현돼야 더 깔끔하고 프론트엔드에서도 구현이 짧아짐!
      → 코드는 짧고 깔끔할수록 best!
    • 프론트엔드 할 때 수정 예정!!
• 회의 19시30분!
  • 스터디는 오늘도 pass

비밀번호 수정 기능 - 변경 기록 3회 이내의 동일한 비밀번호로 변경 불가 옵션

• DB 말고 redis 쓰기
  • entity - redishash 패키지 안에 entity처럼 만들어주기!
• 엔티티 조언 참고 비밀번호 변경 기록과 비밀번호 변경 제한을 구현하기 위해서는 비밀번호 엔티티에 다음과 같은 필드가 필요할 것입니다:

  1. 사용자 ID: 비밀번호 변경과 관련된 사용자의 식별자

  2. 변경된 비밀번호: 변경한 비밀번호 값

  3. 변경 일시: 비밀번호가 변경된 일시

     비밀번호 변경 기록을 저장하고 조회하는 용도로 Redis를 사용할 때, 사용자 ID를 Key로 하고 변경 기록을 Value로 저장하는 방식을 활용할 수 있습니다. 비밀번호 변경 제한은 해당 사용자의 비밀번호 변경 기록을 조회하고, 최근 3회 변경 기록 중 동일한 비밀번호가 있는지 확인하여 처리하면 됩니다.

     아래는 비밀번호 변경 제한을 위한 예시 엔티티 구조입니다:

     javaCopy code
     import java.time.LocalDateTime;
     
     public class PasswordChangeHistory {
         private Long userId;
         private String newPassword;
         private LocalDateTime changeDateTime;
     }

     위와 같은 엔티티를 활용하여 Redis에 비밀번호 변경 기록을 저장하고 조회하면서 변경 제한을 구현할 수 있습니다. 단, Redis의 데이터 유지 기간과 데이터 저장 방식에 유의하여 구현해야 합니다.

• 참고
  • https://www.wool-dev.com/backend-engineering/spring/springboot-redis-database
• UserService - public void updatePassword(UpdatePasswordRequestDto requestDto, User user)
  • 해석

    Password passwordHistory = passwordRepository.findByUsername(requestDto.getPassword());

    • requestDto의 비밀번호를 이용해서 passwordRepository에서 해당 비밀번호를 사용한 기록을 찾는 것을 의미
    • UpdatePasswordRequestDto requestDto: 이 객체는 비밀번호 변경 요청에 필요한 정보를 담고 있는 DTO(Data Transfer Object)입니다. 사용자가 새로운 비밀번호를 입력하고, 해당 비밀번호와 함께 프로필을 수정할 때 사용됩니다.
  • findByUsername(requestDto.getPassword())의 혼동
    • Password passwordHistory = passwordRepository.findByPassword(requestDto.getPassword());는 이전 비밀번호 기록을 조회하는 데에는 적합하지 않음
    • 사용자의 이전 비밀번호 기록을 조회하기 위해서는 사용자의 식별 정보(사용자 이름 또는 ID 등)을 사용하여 조회해야 하기 때문에 변경하기

      Password passwordHistory = passwordRepository.findByUsername(user.getUsername());

      • 사용자의 이름을 기반으로 데이터베이스나 저장소에서 비밀번호 기록을 찾아와서, 그 기록을 passwordHistory라는 변수에 저장
• 해석

  public interface PasswordRepository extends JpaRepository<Password,Long> {
      Password findByUsername(String username);
  }

  • 주어진 사용자 이름으로 해당 사용자의 비밀번호 정보를 데이터베이스에서 찾아 반환
  • redis를 쓰는 Repository는 extends CrudRepository를 사용!
  • extends CrudRepository

    public interface PasswordRepository extends CrudRepository<Password,Long> {
        Password findByUsername(String username);
    }

    • extends CrudRepository를 하면 findByUsername(String username)에 오류가 날 것이고 id 값으로 찾아주면 된다고 합니다…
• 왜 NullpointerException 이 뜨는가?!
  → 18시 팀장님께 일단 말씀 드림!
• redis(noSQL)를 쓰기 때문에 쿼리 메서드를 쓸 수 없다!
  • mySQL 등… 이 쿼리문 가능!
• 변경한 적이 있는지 확인
  • 없을 때 : 바로 변경 비밀번호를 추가
  • 있을 때 :
• isEmpty() : List<> 에서 값이 비어 있는지 비어 있지 않은지 확인!
• isPresent() : Optional<> 에서 값이 비어 있는지 비어 있지 않은지 확인!
• List : List를 감싸고 있는 클래스를 레포클래스!
• 오류!!!!!!! so sad….
  • Been등록 오류, id 이름이 계속 겹치거나 문제가 있어서 UnsatisfiedDependencyException….! → 중단하고 팀장님이 받기로!
  • UnsatisfiedDependencyException 전에 해야 했었던 기능과 바뀔 예정인 것?!
    • password의 id 값의 적은 숫자 순서대로 3개의 제한을 두고 비밀번호 기록이 업데이트 되어야 하는 기능을 구현해야 했음!
    • password의 id 값이 오류가 있기 때문에 적은 숫자의 id값을 이용하지 않고 가장 전에 했던 시간 순서대로 하는 것으로 바꾸어야 할 수도!
    • 정리하자면, 적은 숫자 순서대로의 password id 값을 기준으로 3개의 비밀번호 변경 불가 → 시간 순서를 이용하여 가장 과거에 했던 기준으로 3개의 비밀번호 변경 불가로 변경….!?