Spring 숙련

• JWT?
  • JWT(Json Web Token)란 JSON 포맷을 이용하여 사용자에 대한 속성을 저장하는 Claim 기반의 Web Token
• 로드밸런서 : 중간에서 클라이언트들의 요청을 밸런스 있게 서버에 나눠주는 중간 역할
• 로드밸런서는 무조건 세션1에 정보를 가지고 있는 클라이언트의 요청만 서버1에 주는 것이 아니다
  → 랜덤으로 줄 수 있음
  - 로드밸런의 랜덤 문제점 해결 방법1
  - Sticky Session 방식 : 클라이언트 요청을 서버에 고정(추가 설정)
  - 로드밸런의 랜덤 문제점 해결 방법2
  - 새로운 Session 저장소 생성 : 서버에 어떤 요청이 들어오든 Session 저장소에 모든 클라이언트 정보를 가지고 있다면 해결 가능
  → 계속되는 인증 때문에 서버 부담이 커짐
  - 로드밸런의 랜덤 문제점 해결 방법3
  - JWT : 클라이언트의 JWT로 암호화 하여 로그인 정보 가지고 있음, 모든 서버에서 그 토큰이 들어왔을 때 검증하면 됨(Secret Key를 모든 서버에 동일하게 가지고 있어야 함)
  - Secret Key
  1. 사용자의 로그인 정보를 암호화할 때 사용 → JWT 만들어짐
  2. 받아온 JWT 검증 시 Secret Key 필요
  - JWT, 저장된 쿠키를 만료 시키지는 못하지만 만료 기한을 설정할 수 있음
• 위험!
  • Secret Key 유출 시 조작 가능
  • JWT는 오픈 되어 있음 → 알고리즘을 사용하여 확인 가능
    • JWT에 민감한 정보 넣지 말기
• Set-Cookie : 클라이언트에서 따로 처리 안 해도 자동으로 쿠키 저장소에 Main Value로 담김
• Request에 알맞는 Response 값이 넘어온다!
  • Request 보낼 때 쓰는, Response 받을 떄 쓰는

조장님의 Spring 강의

• @ : 어노테이션은 필요한 코드를 함축하여 적용해주는 기능(Lombok) → 어떤 역할인지 어노테이션을 통해 스프링 시스템에 알려줌(MVC 구조)
  • 컨트롤러 리스폰스디티오 리퀘스트디티오 엔티티 서비스 레포지토리
• view : html, javascript, css
• 어플리케이션 프로포티스, 빌드.글레이드 : 사용 할 프로그램, 비밀번호 등 확인
• 게터, 세터 : 필드에 직접 접근이 아닌 메서드로 우회해서 불러오고 받기 위해 설정
  • 필드에 왜 직접 접근하면 안되나요?
    • 프라이빗은 게터, 세터가 필요!
    • 퍼블릭으로 만들면 아무나 값을 수정할 수 있기 때문에 위험!
      • ex) 스피드는 음수(마이너스)가 디폴트 될 수 없다, 무조건 0! 누구나 접근이 허용(퍼블릭)되면 누군가가 음수로 바꾸고 악용할수도!
• @제너레이티드밸류 아이덴티티 몰라…
  • 아이디 값 자동 생성, 게시글의 넘버링 자동 생성!
• Hibernate : SQL 자동으로 보여주고 설정해주는 값
• Entity를 처음으로 만들고 참고하면서 Dto를 만듦
• 리퀘스트디티오? 리스폰스디티오?
  • DTO : 요청을 보내고 받는 것의 징검다리역학
    → Date Transfer Object : 데이터 전달 객체, 데이터의 통로
• @RequestBody : Body-JOSN에서 값을 받아온 것(RequestDto에 적힌대로 값을 입력해줘야 함 → RequestDto가 통로라고 생각하기)
• CRUD 기능들이 JPA에 다 있음 (ex. JPA의 save 메서드 자동 적용)
• Request(보내줄 때)는 Body 값이 보이지 않음, Response(불러올 때)에서는 값이 보임(숨겨야 할 값 빼줘야 함)
• JPA가 자동으로 넣어주고 Hibernate가 기능함 = 우리는 규격만 맞춰주면 된다!!!!!!!!!!!
• 오류까지 포함하여 겟 조회 넘버링이 됨!
  → 트랜젝셔널에 의해…!? 알아보기!
  - 딜리트 플래그 (안 좋은 상황에 대처하기 위한 디테일)