week_05 SpringBoot 4/?

오늘도 공부 메모

git checkout -f 커밋번호 -> 해당 커밋 시점으로 -> 실습
git checkout -f . & git clean -fd -> 실습 초기화
git checkout main -> 최신으로 돌아오기

 

REST API 프로젝트; 프론트

• next.js
• 스벨트킷 << 난이도 쉬움 thymeleaf 정도 + 퍼포먼스 빠름

@RequiredArgsConstructor와 @Autowired의 차이
final로 선언할 경우, 해당 변수가 생성될 때 값을 넣지 않으면 값을 넣을 수 없음.
필드에 붙은 @Autowired는 해당 클래스 객체 생성 전후에 알아서 적절한 값을 넣어 해당 필드 객체를 생성한다. 이때 final을 붙여두면 @Autowired가 클래스 객체 생성 후에 값을 넣으려다 실패한다.
@RequiredArgsConstructor, @AllArgsConstructor -> 롬복
@Autowired -> 스프링

@Autowired => 생성자/필드의 의존성 주입 목적 (생성자의 경우, 생성자가 하나면 생략 가능)
-> 생성자 의존성 주입 = 생성자에 사용된 필드들이 생성자의 매개변수로 전달되면, 그 생성자를 통해 객체를 생성할 때 해당 필드들의 값이 외부에서 주입되는 것을 의미
@AllArgsConstructor => 갖고 있는 모든 필드 사용한 생성자 생성
@RequiredArgsConstructor => final 붙은 필드만 사용한 생성자 생성
-> 이렇게 만들어진 생성자에 @Autowired가 명시적/암묵적(생성자 하나일때)으로 의존성을 주입함.

 

아이콘 넣기
cdnjs에서 fontawesome 최신 버전 dependencies에 추가
https://fontawesome.com/search?o=r&m=free

 

기능을 추가할 땐 해당 entity부터 만드세요.
그 이후 controller를 만들면서 필요한 것을 추가하세요.
CRUD에 기반하여 작성해둔 것들을 템플릿처럼 활용하며 만드세요.

 

회원가입 흐름
url로 요청하면 get 요청으로 먹힘
렌더링 순서: GET member/join 호출 -> member/join.html 호출 -> global/layout.html 전반부 호출 -> member/join.html 진행 -> global/layout.html 후반부 호출
form 순서: username 입력 -> password 입력 -> submit button 클릭 -> form 발송 시도 -> onsubmit 값인 submitJoinForm 함수 호출 -> 실행 = 유효성 체크 -> form 강제 발송 (form.submit) -> return false에 의해 자연 발송 방지 (유효성 체크 통과한 뒤에 하는 강제 발송만 유효하게 하는 것)
이후 작업: form의 메서드가 post기 때문에 이후에는 POST member/join 호출 -> form 안에서 input 태그의 name에서 username과 password와 일치하는 값만 전송 -> WrtieForm 객체 생성 -> HttpServletRequest req의 payload의 username과 password 필드 값 할당 -> @Valid와 @NotBlank를 통한 유효성 체크 -> 해당 정보를 서비스에 넘김 -> 서비스는 member 객체 조립(생성)하여 repository에게 넘김 -> 새 객체인지 체크 -> 새 id 부여하여 save -> repo 리턴 -> 서비스 리턴 -> 브라우저 url에 메시지 입력 요청 -> 브라우저가 명령 수행하여 url 띄움 -> redirect에 의해 GET member/join 호출 및 메시지 띄움

아이디 비번 일치 체크할 때는 Optional 안 줌... null 들어갔다간 터지니까...
아니야... op인데 비었을 때 get 써서 터진 거임...
Optional은 null 값이 들었는데도 모르고 걍 진행하다가 더 큰 문제가 발생하기 전에
야 이거 비었어! 하게 해주는 것임.

 

쿠키 세션 인증 (Rq)
쿠키 = 가장 안전한 인증(?)
인증 = 인증 확인 + 인증서 발급

 

req = 이미 받은 편지
resp = 이제 보낼 편지 -> 여기에 쿠키(요구서)를 담아야 브라우저로 가겠지? 타임리프(html 생성기)의 결과물인 html도 여기 실리겠지. 그럼 브라우저가 그걸 받아서 렌더링해서 사용자에게 보여주겠지...

 

쿠키

쿠키는 서버에서 생성되어 브라우저에 저장됩니다. 서버에 저장되는 건 세션이에용~
정확히는, 서버에서는 resp에서 쿠키 제작 요구서를 브라우저에 응답합니다.
브라우저는 해당 요구서에 맞추어 쿠키를 저장합니다.
(말하자면 쿠키는 열쇠 같은 거죠. 서버는 열쇠 거푸집을 만들어서 브라우저에 응답하고
서버 자신은 해당 열쇠로 열리는 곳에 브라우저 정보를 저장해 둡니다.
브라우저는 거푸집을 써서 열쇠를 만들고, 다시 서버에 요청을 보낼 때 해당 열쇠의 복사본을 같이 보냅니다. 서버는 그것과 동일한 열쇠로 열리는 정보를 확인하고 맞는 작업을 실시해요. 한번 열쇠를 만들면 브라우저는 요청을 보낼 때마다 해당 열쇠를 지참하기 때문에, 서버는 해당 브라우저가 동일한 브라우저라는 것을 알 수 있습니다. 참, 열쇠는 한 개만 만들지는 않아요. 매번 모든 열쇠의 복사본을 지참합니다.)
F5 누르면 재접속이라서 쿠키가 날아감... 휘이잉~
setPath로 쿠키 활용 영역 지정 가능

 

보통 세션으로 로그인을 관리하고, 쿠키는 사이트 설정, 아이디 저장 등...
세션은 쿠키 위에 얹은 추가 기능 같은 거예용

스프링부트는 web server 보다는 web application server에 가까워용
브라우저랑 직접 통신도 가능하고, 중간에 다른 서버를 낄 수도 있죵
HTTP 서버는 기억력이 없지만 WAS인 스프링부트는 가능하죠.
그게 바로 세션입니당. 하는 일은 얼추 비슷함...