하루 x 365

대용량 트래픽 프로젝트 refresh token 관리에 redis를 다들 쓰시는 것 같아서 redis를 마저 공부하기로 함. 도커를 통해 설치? 하는법을 찾아서 해봤는데 설치만 성공하고 어떻게 쓰는지 감이 안 온다. 다른 방식으로 그냥 받아서 하는것은 ping pong 테스트까진 성공했는데... 음... 막히는 기분이 들어서 토큰 관련 이론공부를 조금 했다. access token 과 refresh token 을 함께 사용해야 하는 이유? 토큰을 하나로만 사용할 경우 인증시간이 길고 해당 토큰이 탈취당할 경우 인증시간이 끝날때까지 대처가 x 리프레쉬 토큰을 함께 사용하면 악세스 토큰만 사용할때보다 위험성이 줄어든다. 악세스 토큰을 탈취당하더라도 유효시간이 짧으며 리프레쉬 토큰은 갖고있는 정보가 없어서 탈..

대용량 트래픽 프로젝트 이번 프로젝트도 벌써 3일밖엔 남지 않았다 발표일 생각하면 2일... 다음주부터 최종 프로젝트인데 걱정이 너무 크다... 어제부로 필수 admin 기능은 전부 구현끝나서 이제부터는 토큰 관련이나 나머지 공부를 해야할것같다... 우선 가장 필수적이라고 생각하는게 페이징 / 스케줄러 / 레디스 이렇게 세가지이다. 그래서 공부를 하는데... 음... 레디스를 먼저 손댄게 잘못인지 설치부터 잘 이해를 못해서... 좀 시간을 오래 잡아먹었다. 오후에는 그래서 잠깐 전환할 겸 팀장님이 올려주신 예외처리 방식을 테스트해봤다. enum이 여러모로 활용도가 높은것같다는 생각이 든다. 아 그리고 중간에 유효성 검증 기능 추가해서 올리다가 기존 코드랑 충돌해서... 그걸 해결하느라 시간이 좀 걸렸다 ..

대용량 트래픽 프로젝트 따로 연습해본 내용을 프로젝트에 적용 중이다. 자신감이 떨어지니 바로 코드를 써도 되나? 하는 생각에 편하게 쓰질 못해서 우선 먼저 연습코드를 쓰고 반영중이다. 인증부분 기본 틀은 강의를 참고하며 만들고 있어서 아직 왜 이렇게 되는가? 를 전부 이해하진 못한 것 같다. queryDSL은 간단한 정도만 작성하는거라면 자료 참고해서 가능한 정도는 되었는데, 여전히 감은 못 잡고있다. 공부를 하는데도 이해도가 늘지 않는 기분이 좀 답답하다. 이날은 git에 pr을 올렸는데 기존 코드와 충돌했다... 다행히 swagger 설정같은거라 중요 파일은 아니어서 잘 해결 되었는데 긴장되는 경험이었다. 체크 : git은 띄어쓰기나 줄바꿈도 인식을 해서 충돌할 수 있으니 그 부분도 신경쓰자! 마무리..

대용량 트래픽 프로젝트 로그인 / 인증기능까지 강의를 다시 참고해서 1차적으로 작성하였다. 예외처리의 경우 임시로 작성해두었고 나중에 통일된 형식으로 처리하기로 했다. refresh token 관련 부분을 적용해보고 싶어서 찾아보는데 음... 개념부터 잘 이해가 안 되는 것 같다. 자료를 보고 적용해서 테이블에 토큰 저장까지는 테스트에 성공을 했는데 이걸 어떻게 활용해야 할지 모르겠다. AdminController @RestController @RequestMapping("/api/admins") class AdminController( private val adminService: AdminService ) { @PostMapping("/signup") fun signUp(@RequestBody req..

대용량 트래픽 프로젝트 queryDSL 강의를 수강하면서 이전에 작업했던 투두 앱 프로젝트에 기능을 추가해보았다. QueryDslSupport abstract class QueryDslSupport { @PersistenceContext protected lateinit var entityManager: EntityManager protected val queryFactory: JPAQueryFactory get() { return JPAQueryFactory(entityManager) } } UserController @GetMapping("/search") @PreAuthorize("hasRole('USER') or hasRole('ADMIN')") fun searchUserList(@RequestP..

대용량 트래픽 프로젝트 로그인 회원가입 기본 틀(부가기능 없음) 만 우선적으로 만들기로 함. 한번 자신감이 떨어지니 이전에 해봤던 기능인데도 잘 할수있을지 걱정이 된다... 오전 회의에서는 폴더 구조 전략을 정했다. 이전 프로젝트에서 어떤식으로 진행했는지 팀장님이 각 팀원들의 의견을 받아 장단점 비교후 반영했다. 오전에는 기본 회원가입과 로그인을 위한 admin dto와 entity를 먼저 작성하였다. 그리고 밀린 강의를 수강하였는데 음... 집중이 잘 안되어서 진도가 많이 나가지 못했다. 듣긴 다 들었는데도 머릿속에 남은게 없는 기분이다. 마무리 지난 주차에서 제대로 학습완료를 못한게 너무 아쉽다. 들은 강의를 내일 다시 복습이라도 해야할 것 같다.

대용량 트래픽 프로젝트 새 프로젝트가 시작되었고 이전 학습주차에 제대로 필요한 기능을 다 습득하지 못해 걱정이 되었다... 시작하자마자 팀장님께 솔직하게 상황을 말씀드리니 전체 진행도에 크게 영향을 주지 않는 파트로 배분해주셨다. 첫날이라서 주제를 정하고 와이어프레임 / erd / api 명세서를 작성하였다. 주제에 맞는 데이터를 찾았는데 첫번째 데이터는 사용하기에 썩 좋은 상태가 아니어서 서울시 쪽 사이트에서 다른 비슷한 자료를 찾아 그걸로 진행하기로 하였다. 마무리 사실 팀 프로젝트에 지금 상황인 내가 제대로 참여할수 있을지 걱정이 된다... 어떻게든 발목만 안 잡을수 있게 최선을 다하는걸로 ㅠㅠ

1. 주특기 플러스 주차 복습과제 닉네임은 이메일로 대체 1/30 - 회원 가입 API 닉네임, 비밀번호, 비밀번호 확인을 request에서 전달받기 닉네임은 최소 3자 이상, 알파벳 대소문자(a~z, A~Z), 숫자(0~9)로 구성하기 비밀번호는 최소 4자 이상이며, 닉네임과 같은 값이 포함된 경우 회원가입에 실패로 만들기 비밀번호 확인은 비밀번호와 정확하게 일치하기 데이터베이스에 존재하는 닉네임을 입력한 채 회원가입 버튼을 누른 경우 "중복된 닉네임입니다." 라는 에러메세지를 response에 포함하기 회원 가입 버튼을 누르기 전, 같은 닉네임이 존재하는지 "확인" 버튼을 눌러 먼저 유효성 검증부터 할 수 있도록 해보기 (챌린지 과제) 데이터베이스에 비밀번호를 평문으로 저장하는 것이 아닌, 단방향 암..

1. 주특기 플러스 주차 복습과제 닉네임은 이메일로 대체 1/30 - 회원 가입 API 닉네임, 비밀번호, 비밀번호 확인을 request에서 전달받기 닉네임은 최소 3자 이상, 알파벳 대소문자(a~z, A~Z), 숫자(0~9)로 구성하기 비밀번호는 최소 4자 이상이며, 닉네임과 같은 값이 포함된 경우 회원가입에 실패로 만들기 비밀번호 확인은 비밀번호와 정확하게 일치하기 데이터베이스에 존재하는 닉네임을 입력한 채 회원가입 버튼을 누른 경우 "중복된 닉네임입니다." 라는 에러메세지를 response에 포함하기 회원 가입 버튼을 누르기 전, 같은 닉네임이 존재하는지 "확인" 버튼을 눌러 먼저 유효성 검증부터 할 수 있도록 해보기 (챌린지 과제) 데이터베이스에 비밀번호를 평문으로 저장하는 것이 아닌, 단방향 암..

1. 주특기 플러스 주차 복습과제 닉네임은 이메일로 대체 1/30 - 회원 가입 API 닉네임, 비밀번호, 비밀번호 확인을 request에서 전달받기 닉네임은 최소 3자 이상, 알파벳 대소문자(a~z, A~Z), 숫자(0~9)로 구성하기 비밀번호는 최소 4자 이상이며, 닉네임과 같은 값이 포함된 경우 회원가입에 실패로 만들기 비밀번호 확인은 비밀번호와 정확하게 일치하기 데이터베이스에 존재하는 닉네임을 입력한 채 회원가입 버튼을 누른 경우 "중복된 닉네임입니다." 라는 에러메세지를 response에 포함하기 회원 가입 버튼을 누르기 전, 같은 닉네임이 존재하는지 "확인" 버튼을 눌러 먼저 유효성 검증부터 할 수 있도록 해보기 (챌린지 과제) 데이터베이스에 비밀번호를 평문으로 저장하는 것이 아닌, 단방향 암..