버그 찾다 끝나는 하루

UserDetails 스프링 시큐리티가 사용자 정보를 알 수 있도록 사용자에 대한 정보를 저장하는 인터페이스이다. 즉 스프링 시큐리티가 개발자 대신에 내부적으로 사용자 정보를 알 수 있도록 UserDetails 인터페이스를 상속받아서 스프링 시큐리티가 필요한 정보들을 구현해야한다. 다음과 같이 User 클래스에 UserDetails를 상속받아서 시큐리티가 필요한 정보를 구현할 수 있다. 이렇게 설정을 하면 스프링 시큐리티는 사용자를 시큐리티 정보에 구성하기 위한 최소한의 정보를 내부적으로 저장하게 된다. @Entity @Getter public class User implements UserDetails { @Id @GeneratedValue private Long id; private String us..

스프링에서 의존관계 자동주입을 하는데, 자동주입 할 대상이 2개 이상이 존재하면 어떻게 구분을할까? 스프링은 사용자가 @Autowired를 붙여주는 의존관계 자동주입 이외의 일을 하지 않는다면, 자동주입 할 대상이 2개 이상이면 NoUniqueBeanDefinitionException 예외를 터뜨린다. 따라서 의존관계 주입할 대상이 2개 이상이면 사용자가 어떤 대상에게 우선권을 줄것인지, 아니면 어떤 비즈니스 로직에 어떤 주입을 할 것인지에 대한 처리를 해야한다. 만약 여기서 자동주입이 잘 안된다는 이유로 인터페이스가 아닌 구현체로 자동주입을 명시하면 DIP를 위반하고 유연성이 떨어지기 때문에 그런일은 하지 않길 바란다. 본격적으로 해결방법을 알아보자. 조회 대상 빈이 2개 이상일 때 해결 방법은 다음과..

@RequestMapping 스프링은 애노테이션을 활용한 매우 유연하고, 실용적인 컨트롤러를 만들었는데, 바로 @RequestMapping 애노테이션을 이용한 컨트롤러이다. 과거에는 스프링 프레임워크가 MVC부분이 약해서 스프링을 사용하는 개발자들은 MVC부분은 다른 프레임워크 기술을 사용했었다고 한다. 그런데 @RequestMapping이 등장하고 나서 MVC 부분이 강해지면서 스프링의 완승으로 끝났다고 한다. 그럼 바로 @RequestMapping 이 무엇인지 알아보자. 해당 포스팅은 스프링 MVC의 내부 동작원리를 다 안다고 가정하에 진행한다. HTTP요청이 들어오면 핸들러 매퍼와 핸들러 어댑터를 통해서 핸들러를 찾고 실행하는 것을 다들 알 것이다. 동작원리를 모른다면 다음 링크를 통해서 알아보고 ..

스프링 MVC의 내부 동작원리에 대해서 공부해보았다. 스프링 MVC 는 프론트 컨트롤러 패턴과 어댑터 패턴을 사용해서 필요한 부분만 사용할 수 있게 유연하게 HTTP 요청을 처리하고 응답한다. 오늘은 HTTP Message Body에 JSON 형식과 같은 결과값을 반환하는 방식이 아닌 뷰를 렌더링을 해서 사용자에게 화면을 보여주는 FrontController 패턴을 공부하였는데, 동작원리는 대략적으로 공부하면서 그린것을 바탕으로 보면 다음과 같다. 그림이 좀 허접해도 양해좀 부탁드리면서.. 자세한 동작원리는 다음과 같다. 이 때, 클라이언트가 웹 서버에 HTTP 요청을 한다고 가정한다. 프론트 컨트롤러(FrontController)는 사용자의 HTTP 요청에 따라서 HTTP Request Header의 ..

웹 사이트에 클라이언트에게 오류 상황을 보여줄 때에는 HTML 파일로 정적으로 예외 페이지를 보여주면 되었다. 그런데 클라이언트가 API를 잘못된 형식으로 호출하거나 서버 내부에 오류가 생기면 정적인 HTML 예외 페이지를 보여주면 안될 것이다. 이럴때 API 예외처리는 스프링 MVC는 어떻게 처리를 할까? 클라이언트가 API를 잘못된 요청으로 호출하거나 서버 내부에 오류가 있다면 서버는 이런 형식으로 API 예외를 반환해야 할 것이다.(JSON 형식으로 요청한다면) { "message": "잘못된 사용자", "status": 500 } { "message": "잘못된 요청", "status": 400 } BasicErrorController 우선적으로 웹 사이트에서 클라이언트에게 오류 페이지를 보여주는..

어떤 웹 사이트를 방문하여 어떤 작업을 하는데에 있어서 로그인을 하는것은 거의 필수적이다. 스프링은 다양한 방식으로 로그인 처리를 할 수 있는데 한번 살펴보자. 쿠키, 세션을 사용하여 로그인 처리를 해볼 건데 말로 설명하면 대략 이런 순서대로 동작하는 로직이 될 것이다. 사용자가 로그인 화면에 접속하여 자신의 아이디와 비밀번호를 입력한다. 아이디와 비밀번호가 맞지 않는다면 경고 메시지를 출력하며 다시 입력하라고 한다. 아이디가 맞다면 다음으로 넘어간다. 아이디에 해당하는 회원정보를 데이터베이스에서 가져온다. 화면이 로그인된 상태의 화면으로 바뀐다. 하지만 마지막 과정인 3번은 쿠키와 세션을 사용하지 않는다면 동작하지 않을것이다. 왜냐하면 웹 페이지는 정적인 페이지이기 때문에 웹 서버에 쿠키를 전달해야 3..

스프링의 검증 기능을 Validation 부분에서 살펴보았는데, 일일이 코드로 작성해야 한다는 점이 매우 불편하다. 개발자는 게으르다는 소리가 여기서 나오지 않나 싶다.. 스프링부트는 전에 일일이 작성했던 Validation 부분을 통합하여 관리해서 제공해주는데, 처음에 검증 코드를 일일이 작성할때와 비교해보면 스프링부트가 제공해주는 Bean Validation을 사용할 때 뭔가 혁신적인 느낌이 들었다. 무엇인지 바로 알아보자. 다음은 내가 예전에 일일이 작성했던 검증 부분과 스프링 부트가 제공해주는 애노테이션 기반 검증 부분의 코드이다. if(item.getPrice() == null || item.getPrice() 1000000){ bindingRe..

웹사이트에서 회원가입할 때 어떤 문자를 잘못 입력한적이 있을 것이다. 이 때, 잘 설계된 웹사이트는 오류를 친절하게 설명하면서 우리가 작성한 폼을 유지시켜주면서 다시 작성하라고 했을 것이다. 그러나 잘못 설계되거나 친절하지 않은 웹사이트는 오류를 친절하게 설명해주지 않을 뿐더러 우리가 작성했던 폼도 유지시켜주지 않을 것이다. 잘 설계된 웹 서비스는 폼 입력시 오류가 발생하면, 고객이 입력한 데이터를 유지한 상태로 어떤 오류가 발생했는지 친절하게 알려주어야 할 것이다. 비밀번호 입력 같은 기능의 경우는 보안적인 문제가 있기 때문에 제외하면 말이다. 이런 것을 처리해주는 Spring MVC와 Spring Boot가 제공하는 기능들에 대해서 알아보자. 우선 Spring이 제공하는 기능들을 쓰지 않고 순수한 자..

스프링에서 메시지 바디(Message Body)에 데이터를 넣어서 서버로 HTTP 요청을 하거나 반대로 서버로부터 HTTP 응답을 받아서 메시지 바디(Message Body)에 있는 데이터를 불러올 때 @RequestBody와 @ResponseBody 애노테이션을 거의 대부분의 스프링 사용자들은 사용할 것이다. @RequestBody와 @ResponseBody는 애노테이션 하나만으로 아주 유연하게 처리할 수 있는 장점이 있다. 이것은 다 HTTP 메시지 컨버터 덕분이 아닌가 싶다. @ResponseBody를 사용하면 어떤식으로 동작하게 되는지 간단히 알아보자. @ResponseBody의 사용 원리 HTTP Message Body에 문자 내용을 직접 반환한다. HttpMessageConverter가 동작하..