올리브영 코테는 둘 다 풀만했지만 세밀한 부분에서 제대로 풀이를 하지 못했다. 이 정도면 아예 못 풀 난이도는 아닌데, 역시 지금 단계에서는 많이 풀어보는게 좋겠다.
스크럼을 하며 enum을 팩토리로 사용할 때, autowired가 안 돼서 고민이라는 제인의 상황을 들었다. 딕셔너리를 하나 만들어주면 될 듯 한데, 나중에 리뷰하며 봐야겠다.
나의 경우는 앞으로 jwt구현을 해야하는데 추가 학습이 좀 필요한 것 같다. 간단하게 정리해서 글을 써봐야 겠다. 글이 밀린게 꽤 있는데 이번 주 안에 마무리해보도록 노력해봐야겠다.
오늘 작성한 기능 구현은 크게 어렵지는 않았다. 다만, 리팩토링을 고려할 수 있는 부분이 보였는데 이전 pr과 스코프가 겹치는 느낌이라 따로 진행하기로 했다. 때문에 주석만 마킹해뒀는데, 이런식이 맞는지 잘 모르겠다. 다음 작업시에 편하긴 한데, 만약 새로운 브랜치로 이어서 진행한다면 불필요한 주석일것이다. 이런 부분도 생각을 해봐야겠다.
지난 주에 풀지 못했던 후보키를 다시 풀었다. 아무리해도 예외케이스를 못 찾겠어서, 답을 보며 비교해봤다. 처음에는 로직 문제가 있나 했는데, 이래저래 해본 결과 로직은 문제가 없었다. 조합을 잘못 구현했는지도 살펴봤지만 그 것도 아니었다.
결국 문제는 index가 1부터 시작하는 것을 고려하지 않고 반복문이 돌아간 것이었다. 계속 index관련한 문제가 생기는데 잘 떠올릴 수 있는 방법을 생각해봐야겠다.
지난주에 하던 StatusLine 리팩토링을 마무리했다. 수정이 끝나고 나니 구조가 꽤 깔끔해졌다. 특히 request쪽 다이어그램이 이제 읽을 수 있는 정도로 바뀌었다. 리버스된 다이어그램을 보며 징후를 파악해보는것도 좋은 방법이라는 것을 알게된 것 같다.
제인이 서비스를 상속구조로 만들어 고생을 하고 있었다. 간단한 해결법으로 빈을 컬렉션으로 받는 방법이 있다고 한다.
새리는 DB예약어와 우리 도메인의 단어가 겹쳐 고민이었다고 한다. 일단은 모두 백틱을 넣는 식으로 설정하기로 했다.
저녁에는 하기로 했던 리팩토링을 간단하게 하고 pr을 보냈다.
슬라이딩 윈도우 문제를 풀었다. 기존에 풀었던 방식은 시간초과다. 따라서 새로운 방법을 생각해봐야했다. 가운데서 홀딩하는 역할을 해주는 것이 필요한데, 대부분 덱으로 구현한 듯 했다. 거기에 착안해서 풀이해봤는데, 여전히 시간초과가 떴다. 아마 중간에 생략해야 하는 부분을 포함하여 반복해서 그런 것 같다. 예전에 문자열 파싱 문제도 슬라이딩 윈도우로 풀 수 있었을 것 같다. 문자열 폭발 문제도 다시 풀어볼 수 있을듯하다.
오늘은 그 동안의 문서 정리와 자잘한 리팩토링 위주로 했다. 이슈를 정리하다보니 fluent builder에 대해서 찾아보게 됐는데, 예시에서는 인터페이스로 나누어 놨었다. 훨씬 깔끔하게 구현되는 것 같다.
새리가 올린 pr 리뷰를 하고 JWT 공부를 이어 나갔다. 아무래토 토큰을 사용한다는 공통점이 있다보니 공부하다 OAuth도 잠깐 보게 됐는데, Open ID Connect라는 방식을 알게 됐다. OAuth에서 API호출을 하는 대신 바로 인증(Authentication)만 하는 방식이라고 한다.
JWT는 계속 보다보니 근본적인 의문이 가시지 않아 결국 스팩 문서를 보게 됐다. 전체를 다 보지는 못 하고 블로그들에서 다루는 주제들만 읽어봤다. 의문점은 디지털 서명과 암호화 방식이 있다고 하는데, 왜 디지털 서명만 나오는지. 그리고 헤더와 페이로드의 파라미터들의 필수 값이 무엇인지와 같은 것들이었다. 제대로 나온곳이 거의 없었다.
그리고 아무데도 Claim에 대해 명확히 설명해주는 곳이 없었는데, 스팩문서의 용어정리에 잘 나와있었다. JWT.io가 공식 홈페이지인 줄 착각했던 것 때문에 많이 돌아온 듯 하다. 블로그로 컨셉을 익히며 키워드를 찾고 해당 키워드로 스팩문서를 찾아보는게 제일 빠른 방법인 것 같다.
오늘은 미션 6을 진행했다. 쿠키를 읽어 로그인 상태를 검증하는 것과 템플릿 엔진같이 동작하도록 만드는 것이었다. 함께 진행하기에 어려울 것 같아 두 가지를 나누어 차례대로 구현하기로 했다.
구현을 다 하고 보니, 뷰 리졸버 역할을 해주는 코드가 필요하다고 느꼈다. 그 외에도 리팩토링이 필요한 부분들이 보였는데, 내일 개선해봐야겠다.
JWT는 시그니쳐를 합치는 부분이 이해가 잘 되지 않아 여기서 일단 멈췄다. 라이브러리를 사용할 때는 키를 이용해서 서명을 하는 것 같았는데, rfc문서에 그 부분이 안 나오는 것 같다. 아마 놓치고 있는 부분이 있을 듯 하다.
그래도 사용에 무리가 없을 정도의 이해도는 올라왔으니 리프래쉬 토큰을 알아봤다. 리프래쉬 토큰을 제대로 사용하려면, 레디스나 디비에 화이트리스트나 블랙리스트로 저장하는 방식을 함께 고려해봐야 할 것 같은데, 이 부분은 내일 스크럼하며 얘기해봐야겠다.
좀 더 확실하게 하는 방법은 ip나 user-agent도 함께 보관하는 방법일 것 같다. 하지만, 결국 중요한 부분은 편의성을 높이면 보안은 허술해질 수 밖에 없다는 것이다. 서비스에 따라 트레이드 오프를 잘 판단해서 적용해야하는 것 같다.
슬라이딩 윈도우에 다시 도전했다. 다시 보니 우선순위 큐를 활용할 수 있을 것 같았다. 생각한대로 잘 풀렸고, 이걸 토대로 덱을 이용한 풀이를 보니 잘 이해됐다. 문자열 폭발에는 우선순위 큐 까지 갈 필요 없이 스택 정도만 써서 예전에 슬빈님이 구현했던 것 처럼 할 수 있을 것 같다.
이외에 일요일 스터디에서 살펴볼 문제들을 풀고 마무리했다. 내일은 최소환승경로를 풀이해봐야겠다.
어제 생각했던 리팩토링을 진행했다. 뷰 리졸버 부분은 아직 건들지 않고 메소드로만 나눠놨다. 전체적인 그림이 살짝 떠올랐기 때문이다.
리스폰스 객체를 사용자들이 실제로 쓸 수 있도록 다듬어서 제공한다면 괜찮을 것이라는 생각이 들었다. 스프링 MVC의 컨트롤러에서 일관성이 조금 떨어진다고 생각했던 부분이 리턴에 관한 부분이었다. 물론 JSON 타입의 리스폰스를 줄 때는 RestController 어노테이션으로 어느정도 해소가 되긴 하지만, 스트링을 바로 리턴해서 페이지로 이동하는 방식은 개인적으로 마음에 들지 않았다. 그래서 혼자 개발할때는 ModelAndView 객체를 직접 리턴하는 방식을 더 선호하는 편이다.
마음에 들지 않는 부분은 리턴 타입으로 어떤 동작을 할지 직관적으로 유추하기 힘들다는 것이다. 물론 조금만 익숙해지면 편한 방식일 수도 있으나, 리턴을 명확하게 지정해주면 더 직관적이지 않을까 하는 생각이다. 그러기 위해서 리스폰스의 하위 타입들을 만들어 처리해주는게 어떤지 생각해보려 한다. 여기서 특정 타입을 고정시키기 위해 함수형 인터페이스를 이용하는 방법도 있을 것 같은데, 한번 잘 생각해봐야겠다.
이외에도 리퀘스트 핸들러도 공통적으로 처리해줘야할 부분들도 처리할 수 있을 것 같다. 다음 주에 좀 더 고민해보고 이슈로 남겨야겠다.
어제 살펴봤던 리프래쉬 토큰을 함께 얘기해봤다. 대략적인 컨셉은 모두 동의하는 것 같은데, 문제는 어디까지 구현 범위로 잡느냐다. 일단은 레디스를 사용해서 관리하는 것 자체는 모두 동의했다. 내가 생각했던 방법은 구현을 해가며 조언을 좀 구해봐야할 것 같다.
오후에는 JWT구현을 직접 해봤다. springboot에서 지원하는 nimbus jose jwt를 사용했는데, 생각보다 로우하게 설정해줘야 해서 조금 당황스러웠다. 잘 찾아보니 jjwt나 auth0보다 좋은 점은 모든 것을 다 지원해주는 점이라고 한다. 이 것만 있으면 JWE를 이용해 메일 인증같은 부분도 구현할 수 있다고 한다. 그리고 공부했던 부분과 메소드 사용법도 거의 일치해서 조금만 찾아보니 크게 어려운 점은 없었다.
한 가지 더 불편하다 느낀 점은 hmac방식을 사용할때 키 길이를 256비트 이상으로 사용해야 한다는 점이었는데, 다른 라이브러리는 자동으로 해싱을 해주는 것 같았다. 굳이 불편한 점이라면 이 정도인데 어차피 UUID를 사용하면 크게 문제없는 것 같다.
테스트는 설계된 것 같고 한 가지 고려해야할 점은 객체 검증 시 exp는 피해서 검증해야 한다는 점이다. 이 부분이 약간의 난관이 될 듯한데 이외에는 큰 문제 없을거라 생각된다.
포스트스쿼드
MockMvc 분석
잭슨 리퀘스트 바디 파싱 분석
그런 REST로 괜찮은가
OS
AWS 강의듣기
s3 이용
sticky session
Powered with by Gatsby 2.0