본문 바로가기

분류 전체보기191

23.07.18 태그 기능 구현을 마치고 테스트를 위해 코드를 실행해봤으나 회원가입/로그인 이후에 JWT토큰을 입력하고 글을 생성하는 등 모든 작업이 403 에러를 발생시키면서 작동하지 않는 상황이 발생했다. 이 부분은 어진님이 해결해주셨다. 태그 기능은 테스트 결과 태그와 글 간의 연관관계를 제대로 맺지 않아서 태그를 가지고 있는 글을 조회하는 메서드가 작동하지 않는 에러가 발생했다. 이 문제는 내일 해결하기로 했다. 2023. 7. 18.
23.07.17 프로젝트는 배달의 민족과 Thread 중에서 고민을 했다. 배달의 민족은 익숙하기도 하고, 장바구니와 같은 기능을 구현해보는 경험이 생기면 좋을 것 같다는 점이 끌렸고, Thread는 배달의 민족과 달리 하드코딩이 적고, 백오피스라는 주제를 살리기 좋을 것 같아 두 프로젝트를 고민하게 되었다. 결국 하드코딩의 부담감 때문에 Thread를 만들기로 했다. 프로젝트의 방향을 정하고, 우선 erd부터 만들기로 했다. https://lucid.app/documents/view/97959506-3e2c-429d-8ac9-c42f6888dafb Dtogram: Lucidchart Lucidchart 문서를 확인하세요! Lucidchart는 팀이 복잡성을 명확히 하고 통찰력을 조정하며 미래를 더 빠르게 구축할 수 있.. 2023. 7. 17.
23.07.16 오늘은 알고리즘을 풀며 마무리를 하려고 한다. Stack이나 Que 등의 자료구조들이 가지고 있는 메서드를 대부분 안다고 자부하였었으나 Deque의 addFirst, addLast 등의 끝부터 더하는 메서드나, peek과 element 처럼 동작은 같으나 에러 처리를 null로 하느냐 false로 하느냐와 같이 에러 처리를 다르게 하는 메서드들이 있는 것은 처음 알게 되었다. 이 외에도 다른 메서드들을 찾아보고, 어떤 차이점이 있는지 공부할 생각이다. 다음주는 아웃소싱 프로젝트를 진행할 예정인데, 과연 어떤 방식으로 진행될지, 그리고 나 자신이 잘 해낼 수 있을지 걱정이 되면서도 기대가 되는 한 주다. 2023. 7. 16.
23.07.14 어제 확인해본 내용과 상이한 글을 확인해 Refresh토큰에 대해 다시 알아보려 한다. 어제 확인한 글에서는 random string이나 uuid로 만들어야 서버측에서 탈취단한 토큰을 삭제할 수 있다고 했는데, 서버에 저장하는(stateful) 방식만 취한다면 JWT토큰이여도 삭제할 수 있다고 한다. 또한 refresh 토큰을 저장하는 위치도 cookie, session, local storage 등 다양하던데, 튜터님은 셋 모두 각자의 장단점이 있을 뿐 어디에 저장하든 탈취당하지 않도록 관리하는 방법 자체가 중요하니 당장은 구현하기 쉬운 곳에 구현하는 것이 좋다고 말씀하셨다. 저장 위치에 따른 장단점은 아래 블로그를 참고하자. https://velog.io/@jisu2281l/TIL-Refresh-To.. 2023. 7. 14.