Spring

로그인시 쿠키를 사용해서 로그인 id를 전달해서 로그인을 유지할 수 있다. 하지만 쿠키만 사용할 경우 심각한 보안 문제가 있다. 어떤 보안 문제가 있을까? 쿠키 값은 임의로 변경할 수 있다는 것이다. 클라이언트가 쿠리를 강제로 변경하면 다른 사용자가 된다. 즉 위장해

서블릿 필터나 인터셉터가 왜 필요할까? 웹과 관련된 공통 관심사를 해결하라 때로는 로그인한 유저만 접근 가능하도록 만들 필요가 있다. 이럴 경우 어떻게 하면 좋을까? 컨트롤러에서 로그인 여부를 체크하는 로직을 하나나하 작성하면 되겠지만, 모든 컨트롤러 로직에 공통

DispatcherServlet 니 누구야?DispatcherServlet은 크게 보면 서버로 들어온 요청들을, 그 요청들을 담당하는 controller(handler)에 배정시켜주는 역할을 한다. 마치 작업 반장과 같은 느낌! (물론 더 많은 역할을 수행한다.)서블릿

HttpServlet은 뭘까? 클라이언트에서 서버로 요청시, 브라우저는 HTTP 프로토콜에 맞춰서 요청 메서지를 만들어서 서버로 보낸다. > HTTP 요청 메세지 POST /save HTTP/1.1 Host: localhost:8080 Content-Type: appl

깊이 있는 이해를 하기 위해서는 때로는 발전 과정을 알아야한다고 생각한다. Spring으로 만든 웹 애플리케이션은 오랫동안 사용되면서 발전해왔고 지금도 발전 중이다. 발전이란 불편함을 개선하는 점에서 시작된다. 그렇다면 고대의(?) Spring 웹 애플리케이션은 어떤

고대의 서블릿을 찾아서(1)에서는 @WebServlet을 이용하여 클라이언트의 요청 URL을 받고 해당 URL HTTP 요청을 HttpServletRequest 객체를 이용하여 데이터를 파싱 후 HttpServletResponse 객체에 html 코드를 입력하여 응답

지난 시간 템플릿 엔진으로 요청을 처리하는 방법을 배웠다. 템플릿 엔진으로 Http 요청을 처리하니 HTML 문서 코드 부분과 동적으로 자바 코드는 넣는 부분을 나눔으로써 코드 작성이 한결 쉬워졌다. 그러나 문제는 이어진다.하나의 서블릿이나 JSP만으로 비즈니스 로직과

이전까지의 흐름을 살펴본다면 서블릿 -> 템플릿 엔진 -> mvc패턴 이런 흐름으로 점차 발전하였다. 이전의 불편함을 개선하여 조금씩 발전한 형태로 만들어졌다. 이번에는 mvc패턴에서 단점으로 지적되었던 점을 개선한 FrontController를 만들어 볼 것이다.

지금까지의 고대의 서블릿 찾는 여정... 서블릿 -> 템플릿 엔진 -> mvc패턴 -> FrontController 도입 전에 있던 단점을 보안하며 FrontController까지 오게되었다. 왜 view가 필요할까? 전에 있던 단점들은 대부분 중복되는 코드들을 어떻

'작성된 코드를 보면서 이게 과연 반드시 필요한 것일까?' 라는 의문이 든적이 있지 않는가? ModelView도 같은 질문에서 시작한다. ModelView의 필요성 이전 controller들의 코드를 봐보자 request를 쓰는 곳도 있고 안쓰는 곳도 있다. 심지

고대의 서블릿에서 현재 Spring MVC 프레임워크까지 여정을 살펴보고 있다. 서블릿 -> 템플릿 엔진 -> MVC 패턴 -> FrontController -> view -> ModelView 여정까지 오게 되었다.ModelView 까지 적용한 과정을 간략하게 적어보

서블릿 -> 템플릿 엔진 -> MVC 패턴 -> FrontController 까지 왔다. 특히 FrontController를 직접 만들면서 HTTP 요청을 처리할 수 있는 다양한 버전의 Controller를 만들었다. 그렇다면 하나의 FrontController에서 다

현재 필자의 회사는 springMVC 쓰고 jsp를 쓰면서 데이터를 주고 받을때는 HTTP API를 이용한다. 그래서 도대체 어떻게 데이터를 주고 받는지 파악하기가 힘들었다. 그래서 오늘은 스프링에서 만드는 응답 데이터를 정리하는 시간을 가지려고 한다. 스프링에서 응

뷰 템플릿으로 HTML을 생성해서 응답하는 것이 아니라, HTTP API처럼 JSON 데이터를 HTTP 메세지 바디에서 직접 읽거나 쓰는 경우 HTTP 메세지 컨버터를 사용하면 편리하다. 그렇다면 HTTP 메세지 컨버터는 어떻게 동작하는걸까?스프링 MVC는 다음의 경우

자바는 멀티 스레드를 지원한다. 메인 스레드 외에 스레드를 사용하려면 어떻게 하면 될까? 스레드를 만들고 쓰면 된다. 자바는 이를 위해 Runnable 인터페이스와 Thread 클래스를 제공한다.Runnable 타입의 객체를 만든다. 스레드 생성시 Runnable타입

이전 글에서 Runnable 인터페이스와 Thread 클래스를 사용하여 자바에서 main 스레드 외에 스레드를 직접 만들어서 사용하는 방법을 공부했다. 이번에는 스레드를 활용할 때 생길 수 있는 문제인 동시성 문제에 대해서 공부해볼 것이다. UserService 객체를

도입부 - 왜 JDBC를 알아야하지? 프로그래밍 공부를 하면서 느끼는 것은 외부적으로 기술 사용 방법도 중요하지만, 내부 동작원리를 이해하는 것이 중요함을 느낀다. 작년 부트캠프에서 스프링부트로 웹 애플리케이션을 뚝딱(뭐 뚝딱은 아니지만,,) 만들면서 발생한 여러가지

커넥션 풀이 왜 필요할까? 커넥션을 획득할 때 복잡한 과정을 거치기 때문이다. 이는 시간도 많이 소모되며 결과적으로 응답 속도에 영향을 준다. 응답 속도가 늦어지는 것은 곧 사용자에게 부정적인 경험을 하게 만드는 것이다. 따라서 이러한 문제를 해결하기 위해 커넥션을

content-type에 따라 어떤 어노테이션을 써야하는지 매번 헷갈렸다.램이 작은 나를 위해 아주 간단하고 명료하게 정리하려고한다. 또 잊어버릴 미래의 나를 위해 content-type을 간단하게 설명하자면, content-type이란 말 그대로 콘텐츠의 타입이다.

바로 전에는 content-type에 따른 어노테이션을 정리하였다. 지난 글을 보면 @Valid가 보였터인데, content-type에 따른 어노테이션을 정리하기 위한 코드가 아니라, 검증 구현을 어떻게 할지 코드를 작성중이였다. 각설하고 오늘 정리할 내용은 스프링의

차비와 시간을 아낄겸(집에서 회사까지 4km) 출퇴근용으로 로드 바이크를 당근에서 구매했다. 쌩쌩 잘나가는 자전거를 타고 매일 재밌게 출퇴근을 했다. 어느 날 자전거를 타고 퇴근 중 가볍게 차와 부딪히게 되었다. 그 이후 나는 자전거를 더 조심히 타게 되었다. 이렇게