스프링

[스프링 MVC 2편] 로그인 처리1 - 쿠키, 세션

로그인 요구사항 홈 화면 - 로그인 전 회원 가입 로그인 홈 화면 - 로그인 후 본인 이름(누구님 환영합니다.) 상품 관리 로그 아웃 보안 요구사항 로그인 사용자만 상품에 접근하고, 관리할 수 있음 로그인 하지 않은 사용자가 상품 관리에 접근하면 로그인 화면으로 이동 회원 가입, 상품 관리 프로젝트 생성 프로젝트 설정 순서 login-start의 폴더 이름을 login로 변경하자. 프로젝트 임포트 File Open 해당 프로젝트의 build.gradle을 선택하자. 그다음에 선택창이 뜨는데, Open as Project를 선택하자. ItemServiceApplication.main()을 실행해서 프로젝트가 정상 수행되는지 확인하자. 색상 추가 Annoation Process 추가 package 구조 he..

[스프링 MVC 2편] 검증2 - Bean Validation

Bean Validation - 소개 검증 기능을 지금처럼 매번 코드로 작성하는 것은 상당히 번거롭다. 특히 특정 필드에 대한 검증 로직은 대부분 빈 값인지 아닌지, 특정 크기를 넘는지 아닌지와 같이 매우 일반적인 로직이다. 아래 코드를 보자. public class Item { private Long id; @NotBlank private String itemName; @NotNull @Range(min = 1000, max = 1000000) private Integer price; @NotNull @Max(9999) private Integer quantity; //... } 이런 검증 로직을 모든 프로젝트에 적용할 수 있게 공통화하고, 표준화한 것이 바로 Bean Validation이다. Bean..

[스프링 MVC 2편] 검증1 - Validation (2)

오류 코드와 메시지 처리 3 오류 코드를 만들 때 다음과 같이 자세히 만들 수도 있고, required.item.itemName : 상품 이름은 필수입니다. 또는 다음과 같이 단순하게 만들 수도 있다. required : 필수 값입니다. 단순하게 만들면 범용성이 좋아서 여러 곳에서 사용할 수 있지만, 메시지를 세밀하게 작성하기 어렵다. 반대로 너무 자세하게 만들면 범용성이 떨어진다. 가장 좋은 방법은 범용성으로 사용하다가, 세밀하게 작성해야 하는 경우에는 세밀한 내용이 적용되도록 메시지에 단계를 두는 방법이다. 쉽게 말하면 더 구체적인 오류코드의 우선순위를 높이는 것이다. 스프링은 MessageCodesResolver라는 것으로 이러한 기능을 지원한다. 오류 코드와 메시지 처리 4 MessageCodes..

[스프링 MVC 2편] 검증1 - Validation

검증 요구사항 요구사항: 검증 로직 추가 타입 검증 가격, 수량에 문자가 들어가면 검증 오류 처리 필드 검증 상품명: 필수, 공백X 가격: 1000원 이상, 1백만원 이하 수량: 최대 9999 특정 필드의 범위를 넘어서는 검증 가격 * 수량의 합은 10,000원 이상 클라이언트 검증, 서버 검증 클라이언트 검증은 조작할 수 있으므로 보안에 취약하다. 서버만으로 검증하면, 즉각적인 고객 사용성이 부족해진다. 둘을 적절히 섞어서 사용하되, 최종적으로 서버 검증은 필수 API 방식을 사용하면 API 스펙을 잘 정의해서 검증 오류를 API 응답 결과에 잘 남겨주어야 한다. 먼저 검증을 직접 구현해보고, 뒤에서 스프링과 타임리프가 제공하는 검증 기능을 활용해보자. 검증 직접 처리 - 소개 상품 저장 성공 사용자가..

[스프링 MVC 2편] 메시지, 국제화

메시지, 국제화 소개 메시지 기획자가 상품명이라는 단어를 모두 상품이름으로 고쳐달라고 하면 어떻게 해야할까? 여러 화면에 보이는 상품명, 가격, 수량 등, label 에 있는 단어를 변경하려면 화면들을 다 찾아가면서 모두 변경해야 한다. 화면 수가 적으면 문제가 되지 않지만 화면이 수십개 이상이라면 수십개의 파일을 모두 고쳐야 한다. 이런 다양한 메시지를 한 곳에서 관리하도록 하는 기능을 메시지 기능이라 한다. 예시 messages.properties (메시지 관리용 파일) item=상품 item.id=상품 ID item.itemName=상품명 item.price=가격 item.quantity=수량 사용 예시 HTML들은 다음과 같이 해당 데이터를 key 값으로 불러서 사용. 국제화 메시지에서 설명한 메..

[스프링 MVC 2편] 타임리프 - 스프링 통합과 폼

타임리프 스프링 통합 타임리프는 스프링 없이도 동작하지만, 스프링과 통합을 위한 다양한 기능을 편리하게 제공한다. 그리고 이런 부분은 스프링으로 백엔드를 개발하는 개발자 입장에서 타임리프를 선택하는 하나의 이유가 된다. 스프링 통합으로 추가되는 기능들 스프링의 SpringEL 문법 통합 ${@myBean.doSomething()}처럼 스프링 빈 호출 지원 편리한 폼 관리를 위한 추가 속성 th:object (기능 강화, 폼 커맨드 객체 선택) th:field , th:errors , th:errorclass 폼 컴포넌트 기능 checkbox, radio button, List 등을 편리하게 사용할 수 있는 기능 지원 스프링의 메시지, 국제화 기능의 편리한 통합 스프링의 검증, 오류 처리 통합 스프링의 변..

[스프링 MVC 2편] 타임리프 - 기본 기능

타임리프 특징 서버 사이드 HTML 렌더링 (SSR) 네츄럴 템플릿 스프링 통합 지원 서버 사이드 HTML 렌더링 (SSR) 타임리프는 백엔드 서버에서 HTML을 동적으로 렌더링 하는 용도로 사용된다. 네츄럴 템플릿 타임리프는 순수 HTML을 최대한 유지하는 특징이 있다. 타임리프로 작성한 파일은 HTML을 유지하기 때문에 웹 브라우저에서 파일을 직접 열어도 내용을 확인할 수 있고, 서버를 통해 뷰 템플릿을 거치면 동적으로 변경된 결과를 확인할 수 있다. 이렇게 순수 HTML을 그대로 유지하면서 뷰 템플릿도 사용할 수 있는 타임리프의 특징을 네츄럴 템플릿 (natural templates)이라 한다. 스프링 통합 지원 타임리프는 스프링과 자연스럽게 통합되고, 스프링의 다양한 기능을 편리하게 사용할 수 있..

[스프링 MVC 1편] PRG Post/Redirect/Get, RedirectAttributes

PRG Post/Redirect/Get 심각한 문제를 가지는 구조 웹 브라우저의 새로 고침은 마지막에 서버에 전송한 데이터를 다시 전송한다. 상품 등록 폼에서 데이터를 입력하고 저장을 선택하면 POST /add + 상품 데이터를 서버로 전송한다. 이 상태에서 새로 고침을 또 선택하면 마지막에 전송한 POST /add + 상품 데이터를 서버로 다시 전송하게 된다. 그래서 내용은 같고, ID만 다른 상품 데이터가 계속 쌓이게 된다. PRG패턴으로 해결한 구조 웹 브라우저의 새로 고침은 마지막에 서버에 전송한 데이터를 다시 전송한다. 새로 고침 문제를 해결하려면 상품 저장 후에 뷰 템플릿으로 이동하는 것이 아니라, 상품 상세 화면으로 리다이렉트를 호출해주면 된다. 웹 브라우저는 리다이렉트의 영향으로 상품 저장..