오늘 겪은 문제 유저 권한에 대한 정보를 JWT 에 담아서 발행한 후 권한 정보 확인이 필요한 요청이 들어올 시 JWT 에 담아뒀던 정보를 확인하고자 했다. 권한은 미리 정해놓은 것들 외에는 들어가면 안 된다고 생각하여 enum을 활용했다. JWT 발행 시 "auth"라는 키에 enum 객체를 value로 집어넣고 추후 확인 시 == 연산을 통해 enum 객체와 일치하는지 확인했다. enum 은 생성자가 private 이라 객체가 하나만 만들어지는 것으로 알고 있었고 따라서 == 연산 시 당연히 내가 원하는 결과가 나올 것이라 생각했다. 하지만 true 가 나오기를 기대했던 연산에 대해서 false 가 나와 혼란스러웠다. 해결 방법 JWT 발행 시 집어넣었던 enum 객체가 다시 확인할 때는 String..

오늘 겪은 문제 JWT 유효성 검사를 하는 커스텀 필터를 만들어 UsernamePasswordAuthenticationFilter 이전에 추가하여 유효하지 않은 토큰일 경우 response 에 에러 메시지를 담아 반환하게 했다. 그리고 유효한 토큰일 경우에만 Security Context에 인증 객체를 저장하도록 해서 만약 토큰이 비어있는 경우에는 다음 필터에서 걸러지도록 코드를 작성했다. 그런데 유효하지 않은 토큰에 대해서는 올바르게 처리가 됐지만 빈 토큰(null) 으로 요청을 보낼 경우 필터에서 걸러지지 않고 컨트롤러를 통과해버리는 문제가 있었다. 시도해본 것 1. token == null 일 경우 커스텀 필터를 통과하지 못 하도록 처리 이 방법으로 빈 토큰에 대한 필터링은 가능했으나 애초에 토큰이..

스프링 시큐리티에 대해 학습하던 중 의문이 생겼다. 학습한 내용을 바탕으로 생각했을 때 Security Context 에 있는 인증 객체(Authentication)를 통해 인증이나 인가와 관련된 처리를 하는 것으로 이해했다. 그런데 우리가 만들 서비스의 유저는 1명이 아닌데 모든 유저들의 인증 객체가 하나의 Security Context 에 저장이 된다면 어떤 인증 객체가 어떤 유저에 대한 정보를 가지고 있는지를 어떻게 구분하는 걸까?? 과거에 세션, 쿠키를 이용한 인증 방식에서 하나의 Sesseon ID 마다 서버에 하나의 세션 저장소가 만들어지고 이 저장소 안에 담긴 객체를 통해 인증이 이루어진다고 학습했다. 그래서 Security Context 에서도 이와 유사하게 하나의 Sesson ID 와 하..

오늘은 시니어 멘토님의 특강이 있었다. 사전에 질문을 받아서 그 질문에 대해 답변을 해주는 방식으로 진행됐다. 많은 사람들이 질문을 남겼는데 공통적이었던 부분은 '항해 끝나고 뭐 공부해야 하나요?'였던 것 같다. 나 역시도 정해진 커리큘럼을 따라가다가 홀로서기를 해야하는 순간부터 무엇을 어떻게 공부해야 하는 가에 대한 고민이 있었기에 주의 깊게 들었다. 시니어 멘토님께서 핵심적으로 강조하신 부분은 '개선'이었다. 백엔드 개발자로서 하는 업무가 보통 CRUD의 연장선이고 어느정도 CRUD에 익숙해졌다면 스프링에 대한 공부, 디자인 패턴에 대한 공부 등을 통해 내 코드를 개선하는 데에 초점을 맞추고 학습하는 것을 추천해주셨다. 그리고 또 항해에서 추후 실전 프로젝트 주차 때 서비스 런칭팀과 챌린지팀을 나눠서..

이번주 WIL은 IoC, DI 그리고 Bean 에 대해서 정리를 해야 하는데 사실 평일에 IoC와 DI에 대해서는 간략히 정리한 글이 있어 WIL 에서는 Bean 에 대해서만 정리하고자 한다.(IoC, DI) Bean 빈은 스프링의 IoC 컨테이너가 관리하는 자바 객체를 의미한다. 그냥 자바만을 사용할 때는 객체를 사용하기 위해서는 직접 new 를 통해 객체를 만들어줘야 했지만 스프링 프레임워크에서는 우리가 따로 객체를 생성하지 않아도 Bean 으로 지정만 해주면 프레임워크가 객체를 만들어서 필요한 곳에 주입해준다. 빈으로 등록하고 싶은 클래스에 @Component 어노테이션을 붙이고 Application 에 @ComponentScan 어노테이션을 붙여 어플리케이션을 실행시키면 @Component 가 붙..

오늘 겪은 문제 오늘은 페어와 함께 스프링부트로 간단한 인증/인가가 적용된 CRUD 게시판을 만드는 작업을 했다. 팀원이 작성했던 Lv1 코드를 기반으로 기능을 추가하기로 했는데 그 과정에서 예상치 못한 에러를 만났다. 시도해본 방법 1. 서비스 단 디버깅 회원가입 기능을 추가하는 과정에 위와 같은 에러를 만났다. 회원가입 과정은 Lv1 에서 했던 것과 별반 다를바 없이 클라이언트로부터 데이터를 입력 받고, 컨트롤러에서 이를 서비스에 넘긴 후, 서비스에서는 내부 로직에 따라 처리하고 DB에 저장한 후 그 결과를 컨트롤러에게 반환한다. 컨트롤러는 반환받은 결과를 클라이언트에게 전달하는 것으로 회원가입이 마무리가 된다. 컨트롤러는 단순히 데이터를 받고, 전달하는 역할을 수행하기에 서비스 단에서 문제가 있을 ..

IoC 와 DI 에 대해서 정리하려 합니다. IoC 와 DI 가 구체적으로 무엇인지 설명하기 전에 둘 사이의 관계를 짚고 넘어가면 좋을 것 같습니다. IoC 는 어떠한 개념이고 DI는 이러한 개념을 구현하기 위한 디자인 패턴이라고 이해하면 됩니다. IoC(Inversion of Control) 말 그대로 '제어의 역전'입니다. 보통 라이브러리와 프레임워크의 차이를 이야기할 때 '제어권이 누구한테 있느냐?'하는 이야기를 많이합니다. 일반적으로 우리가 개발을 할 때는 제어의 주도권은 당연히 개발자에게 있습니다. 개발자가 원하는 시점에 객체를 생성하고, 메서드를 호출하는 식으로 말이죠. class A { private B b; public A() { this.b = new B(); } } class B { }..

오늘은 스프링 Lv1 과제를 제출했다. 과제를 제로부터 설계하고 만들어가면서 MVC 패턴에 대한 이해를 좀 더 할 수 있었고 설계한 대로 만들었을 때 잘 동작하는 것을 보고 뿌듯함을 느낄 수도 있었다. 그리고 함께 항해를 이어가는 동료가 과제를 하는 데 어려움을 겪고 있어 어떤 게 어려운지 물어봤더니 나처럼 Dto? Entity? 언제 Dto 를 쓰는 거고 언제 Entity 를 쓰는 거지? 이 생성자는 왜 만드는 거지? 이런 부분들에 대한 어려움을 겪고 있었다. 그래서 동료에게 열심히 설명해주었고 동료도 혈이 뚫린 기분이라며 매우 만족했다. 오늘 TIL은 내가 동료에게 알려준 부분에 대해서 정리하려 한다. DTO ? Entity? 먼저 dto 객체와 entity 객체다. @Entity 어노테이션을 붙여서..