Goyummy

쿠키의 보안 문제 쿠키에 memberId를 넣어서 사용하면 보안상의 문제가 있을 수 있다. 해커가 memberId를 바꾸어 다른 유저의 정보를 빼가거나 조작할 수 있다. 이를 막기 위해서는 쿠키에는 유저의 중요한 정보가 담겨 있으면 안되고, 쿠키에 사용되는 id가 시간이 지나면 사용할 수 없도록 만료되어야 한다. 그래서 세션 저장소를 이용해 UUID라는 예측할 수없는 id를 저장하여 사용해야 한다. 이렇게 만든 id를 쿠키에 담아 사용하면, 쿠키에는 유저의 중요한 정보가 담기지 않고, 예측할 수도 없다. 세션 세션 관리가 제공해야 하는 기능 세션 생성 sessionId 생성 (임의의 추정 불가능한 랜덤 값) 세션 저장소에 sessionId와 보관할 값 저장 sessionId로 응답 쿠키를 생성해서 클라이..

앞에서 검증1에서 한 것을 검증 Annotation을 이용하여 간단하게 할 수 있는 방식이다. @Data 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; ... @PostMapping("/add") public String addItem(@Validated @ModelAttribute Item item, BindingResult bindingResult, RedirectAttributes redirectAttributes) { ..

상품명 ... html의 checkbox는 체크를 하지않으면 null이 되는 문제 발생. 체크를 하지않으면 아예 데이터를 넘기지 않음. 수정의 경우에 체크박스를 해제하고 넘기면 아무런 값을 넘기지 않기 때문에 수정이 되지 않을 수 있다. 판매 오픈 체크를 해제한 경우 _open만 전송되는데, 이 경우 스프링 MVC는 _open만 있는 것을 확인하 체크를 해제했다고 판단한다. 그러면 null이 아니라 False로 찍힌다. thymeleaf에서 판매 오픈 th:field="*{open}"을 추가하면 thymeleaf에서 _open 자동생성. 위와 동일한 결과! @ModelAttribute("regions") public Map regions() { Map regions = new LinkedHashMap()..

@Controller public class SpringMemberFormControllerV1 { @RequestMapping("/springmvc/v1/members/new-form") public ModelAndView process() { return new ModelAndView("new-form"); } } @Controller : 스프링이 자동으로 스프링 빈으로 등록한다. (내부에 @Component 애노테이션이 있어서 컴포넌트 스캔의 대상이 됨), 스프링 MVC에서 애노테이션 기반 컨트롤러로 인식한다(RequestMappingHandlerMapping에서 ). @RequestMapping : 요청 정보를 매핑한다. 해당 URL이 호출되면 이 메서드가 호출된다. 애노테이션을 기반으로 동작하기..

FrontController 패턴 특징 ㆍ프론트 컨트롤러 서블릿 하나로 클라이언트의 요청을 받음 ㆍ 프론트 컨트롤러가 요청에 맞는 컨트롤러를 찾아서 호출 ㆍ 입구를 하나로! ㆍ 공통 처리 가능 ㆍ 프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 됨 => 불필요한 반복이 줄어듦 Spring MVC에서는 Front Controller가 Dispatcher Servlet임 요청 흐름 ㆍ 서블릿이 호출되면 HttpServlet 이 제공하는 serivce() 가 호출된다. ㆍ 스프링 MVC는 DispatcherServlet 의 부모인 FrameworkServlet 에서 service() 를 오버라이드 해두었다. ㆍ FrameworkServlet.service() 를 시작으로 여러 메서드가 호출..

클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능 1xx (Informational): 요청이 수신되어 처리중 거의 사용X 2xx (Successful): 요청 정상 처리, 성공 200 OK - 요청 성공 201 Created - 요청이 성공해서 새로운 리소스가 생성됨 생성된 리소스는 응답의 Location 헤더 필드로 식별 202 Accepted - 요청이 접수되었으나 처리가 완료되지 않음 배치 처리 같은 곳에서 사용 예) 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리함 잘 사용하지 않음 204 No Content - 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음 예) 웹 문서 편집기에서 save 버튼 save 버튼의 결과로 아무 내용이 없어도 된다...

HTTP API - 컬렉션 POST 기반 등록 클라이언트는 등록될 리소스의 URI를 모른다. 서버가 새롭게 등록될 리소스의 URI를 생성해줌. 컬렉션 (Collection) 서버가 관리하는 리소스 디렉토리 서버가 리소스의 URI를 생성하고 관리 여기서 컬렉션은 /members 예) 회원 관리 API 제공 회원 목록 /members → GET 회원 등록 /members → POST 회원 조회 /members/{id} → GET 회원 수정 /members/{id} → PATCH(부분 수정), PUT(전체 수정), POST 회원 삭제 /members/{id} → DELETE HTTP API - 스토어 PUT 기반 등록 예) 정적 컨텐츠 관리, 원격 파일 관리 파일 목록 /files → GET 파일 조회 /fi..

데이터 베이스 커넥션 풀이나, 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면, 객체의 초기화와 종료 작업이 필요하다. 스프링 빈은 객체를 생성하고, 의존 관계 주입이 다 끝난 다음에야 필요한 데이터를 사용할 수 있는 준비가 완료된다. 따라서 초기화 작업은 의존 관계 주입이 모두 완료되고 난 다음에 호출해야 한다. 그런데 개발자가 의존 관계 주입이 모두 완료된 시점을 어떻게 알 수 있을까? → 스프링은 의존 관계 주입이 완료되면 스프링 빈에게 콜백 메소드를 통해서 초기화 시점을 알려주는 다양한 기능을 제공한다. 또한 “스프링은 스프링 컨테이너가 종료되기 직전에 소멸 콜백”을 준다. 따라서 안전하게 종료 작업을 진행할 ..

지금까지는 @Bean을 이용하여 설정 정보에 직접 등록할 스프링 빈을 나열했다. 하지만 이렇게 등록해야 할 스프링 빈이 수십, 수백개가 되면 일일이 등록하기도 귀찮고, 설정 정보도 커지고, 누락하는 문제가 발생할 수 있다. 그래서 스프링은 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔이라는 기능을 제공한다. 이때, 스프링 빈의 기본 이름은 클래스명을 사용하되 맨 앞글자만 소문자를 사용한다. 만약 스프링 빈의 이름을 직접 지정하고 싶으면 @Component(”…”)를 사용하면 된다. @Autowired를 사용하면 생성자에서 여러 의존관계도 한번에 주입받을 수 있다. @Component public class OrderServiceImpl implements OrderService{ pri..

클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다. 그래서 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야 한다. → private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하도록 막아야 한다. 스프링 없이. 싱글톤 패턴을 사용하지 않고 public class SingletonTest { @Test @DisplayName("스프링 없는 순수한 DI 컨테이너") void pureContainer() { AppConfig appConfig = new AppConfig(); //1. 조회: 호출할 때마다 객체를 생성 //-> 메모리 낭비가 심함 //-> 싱글톤 패턴을 통해 해당 객체가 1개만 생성되고, 공유하도록 설계하면 된다. MemberService memberS..