TIL🔥

오늘의 트러블 슈팅 어제부터 프론트 구현과 함께 토스 결제 API 연동 개발에 들어갔다. 근데 문제점 1. 401 Unauthorized tossPayments = TossPayments(key); 해주는 과정에서, 키 값이 권한이 없는 거다라는 오류가 주구장창 .......... 분명 공식 사이트에서 받은 값을 잘넣어줬는데 문제가 발생 계속해서 다른 값도 넣어주고 다시 넣어주고를 반복하니 됏다.... 왜 됐지???? 뭔가 뒤에 공백이라던가 .... 이런게 들어간거 같다.... 됐으니뭐 2. 로그인 여부 확인 후, 헤더에 표시되는 메뉴가 달라져야하는데 function checkLoginStatus() { var token = Cookies.get('Authorization'); // 로그인 상태 확인 A..

TCP (Transmission Control Protocol): 연결 지향성 (Connection-Oriented): TCP는 연결을 성립하고 데이터를 전송한 후에는 연결을 종료하는 과정이 포함됩니다. 이는 신뢰성 있고 정확한 전송을 보장합니다. 신뢰성 및 흐름 제어: TCP는 데이터를 세그먼트로 분할하여 전송하고, 수신측에서는 세그먼트를 재조립하여 상위 계층에 전달합니다. 또한, 흐름 제어 기능을 통해 수신측의 처리 속도를 조절하여 과도한 데이터 손실을 방지합니다. 순서 보장: TCP는 데이터의 전송 순서를 보장하여 수신측에서는 정확한 데이터 순서로 재조립합니다. 높은 신뢰성: 오류 복구 기능과 재전송 메커니즘을 제공하여 안정적인 데이터 전송을 보장합니다. 사용 예시: 웹 브라우저의 HTTP 통신, ..

오늘의 헛짓거리 ⚠️ 토큰 검증,인가 시 발생하는 예외처리를 해주는 최상위 필터를 하나 더 만들었따. 빠르게 예외가 발생하는 상황에 대해서만 체킹을 하고 넘어갔는데, 이후 다른 기능을 구현하고 테스트 코드를 실행해보니 에러의 향연... 도대체 어디서 나는 것인가 보니, 로그인 성공 후에 발생했다. 그래서 필터의 순서(?) 설정이 문제인가해서, addFilterBefore()을 이것저것으로 변경해봤다. .addFilterBefore(exceptionHandlerFilter(), JwtAuthenticationFilter.class) 기존 -> 예외는 원하는 바가 나오지만, 로그인 성공 시, 이상한 에러가 뜸 .addFilterBefore(exceptionHandlerFilter(), JwtAuthoriza..

오늘은 너무 많은 것을 햇다 1. 기존 ) 어드민 유저 회원 가입(어드민 토큰을 가지고) -> 변경 ) 초기 어드민을 data.sql로 직접 넣어주고, 이후 추가되는 관리자들은 기존 관리자들이 권한을 가지고 추가해주는 방식 (✅ 구현해야함) 2. 관리자 API는 관리자만 접근 가능하도록 3. 기존) JWT Token 검증 실패 시, log.error 로 로그만 찍어줬는데, 변경 ) ApiException을 던져서 Response를 주도록 수정 - 추가 숙제 ⚠️, 최상위 Filter를 하나 더 만들어서, 예외 처리를 거기서 하도록 해주기 ⚠️ 4. 휴대폰 번호 SMS 인증 기능 50% 구현 완료 (..... 전송까진 됐고, 이제 정리와 redis에 저장하고, 회원 가입 버튼 누르면 확인까지 ㄱㄱ)

깨달은 점 나는 다른 팀원들보다 부족한 점이 많다... 많이 배워가쟈! 화이팅! 그리고 팀의 막내로서(맞나..?) 서기를 맡고 있는데 이후에 보니 너무 중구난방 정리가 되어있었다. 정리를 더 잘 하자! 01/06 자 개발 일지 안건1 : 객체지향의 5가지 원칙중 의존 역전 원칙 코드 컨벤션 추가 설정함! User of(String email, String password…), User of(UserCreateRequest) entity는 request에 의존하지 않고 그 자체로 존재해야 한다고 생각함 Request.toEntity(User) → User of(String email, String password…) 이 부분의 이후 문제점을 발견, Sequence 같은 경우 request가 필요하지 않는데..

최종 프로젝트에 들어갔다. 기존 팀들과 달리 S.A 부터 엄청 세세하게 짰는데, 어렵다... 기능 목록을 먼저 작성하고 → 아키텍쳐 그리고 → 와이어 프레임 → ERD → API 명세서 이런 식으로 진행했는데 사실 API 명세서 작성에 어려움이 많아서 중간 중간에 그만두고 와이어 프레임을 그리고, ERD를 설계한 후에 진행했다. ERD를 설계할 때, 가장 어려웠다. 공연장과 좌석을 연결하여 구성했는데, 처음에는 좌석 안에 이 좌석이 경매석인지 선착석인지를 표기하는 컬럼과 가격 컬럼이 들어있었다. 그런데 생각을 곰곰히 해보니(다른 팀원분이 ㅎ) 좌석의 가격, 판매 타입은 공연장이 아니라 공연에 따라 변동되는 값이기 때문에 공연과 좌석의 복합키로 구성된 공연 별 좌석 가격 테이블을 새롭게 생성하여 가격과 판..

발표 피드백에서 GitHub Action Redis TTL 아키텍쳐 에 대해 들었다. 공부하자 ㅎ 내일....

CardService 클래스에 대한 테스트 코드를 짜는데, 워낙 의존하고 있는 클래스가 많아 Mockito를 활용하기가 너무 어려웟다... given-willReturn 이 너무 많이 사용되고, 상위 엔티티의 id를 참조하는 경우가 많기 때문에, 차라리 H2를 이용하여 실제 값을 넣도록 진행했다. 값들을 저장하는 것은 문제가 Never 없었다. 하지만!! ⚠️ 한 개의 테스트가 끝날 때마다 데이터 값들을 모두 지워줘야 했는데 다른 엔티티의 repository를 직접 사용하는 것이 아니라, service 단을 거쳐서 사용하기 때문에 deleteAll 메서드를 사용할 수 없었다. 그래서 다시 mockito 를 적용해보려하다 장렬히 실패....... 다시 기존으로 돌아와서 여러 서치를 해본 결과 Databas..