🌌 실시간 강의: AWS 클라우드 통합 실습
Spring 기초반을 리마인드하면서 실습했던 것들을 제출하는 시간이었다.
+)이제 깨달았다 나누다가 말았네...???분명히 나눴었는데ㅠㅠ
S3 버킷 CORS 설정은 시간이 걸려서 내일 진행하기로 하셨다.
🍃 스프링 심화반 2주차 -10강
1주차 숙제
//ProductService.java
@Transactional
public Product updateProduct(Long id, ProductMypriceRequestDto requestDto) throws SQLException {
Product product = productRepository.findById(id).orElseThrow(
()->new IllegalArgumentException("해당 아이디가 존재하지 않습니다.")
);
product.update(requestDto);
return product;
}
//Product.java
public void update(ProductMypriceRequestDto requestDto) {
this.myprice = requestDto.getMyprice();
}
이게 내가 바꿨던 코드이고, 문풀 영상에서는 이런 식으로도 구현이 가능하다고 했다.
public Product updateProduct(Long id, ProductMypriceRequestDto requestDto) throws SQLException {
Product product = productRepository.findById(id).orElseThrow(
()->new IllegalArgumentException("해당 아이디가 존재하지 않습니다.")
);
//어노테이션 빼고 그냥 저장해도 됨
//알아서 myprice가 변경되었구나 하고 바꿔서 저장해줌
prouct.setMyprice(requestDto.getMyprice());
productRepository.save(product)
product.update(requestDto);
return product;
}2주차
인증 vs 인가 Authentication vs Authorization
- 인증 (Authentication): 사용자 신원을 확인하는 행위
ex) 출입증 확인 - 인가 (Authorization): 사용자 권한을 확인하는 행위
ex) 방문자와 직원의 경우 접근 가능한 구역을 달리하는 것
ex) 웹 카페 사이트에서 회원 랭킹 별 가능한 첨부파일 크기를 다르게 부여
쿠키와 세션
클라이언트와 서버가 통신을 할 때 api 요청을 보내는데 이때 http 통신 규약을 따르게 되어있다. 그러나 http는 사용자를 구별하지 못한다. 상태를 저장하지 않기(Stateless) 때문이다.
따라서 상태 정보를 유지(Stateful)하기 위해서는 쿠키와 세션이 필요하다.
- 쿠키
- 클라이언트에 저장될 목적으로 생성한, 작은 정보를 담은 파일
- 검사 -> Application에서 확인할 수 있다.
- 세션
-
쿠키는 웹 브라우저에서 저장되었다면, 세션은 서버에서 저장하는 기술
- 사용자가 요청
- 서버에서 세션 ID를 새로 발급해서 응답에 추가
- 웹 브라우저가 응답을 받아서 쿠키에 저장
-
| 쿠키(Cookie) | 세션(Session) | |
|---|---|---|
| 설명 | 클라이언트에 저장될 목적으로 생성한 작은 정보를 담은 파일 | 서버에서 일정시간 동안 클라이언트 상태를 유지하기 위해 사용 |
| 저장 위치 | 브라우져 | 웹 서버 |
| 사용 예시 | 사이트 팝업의 "오늘 다시보지 않기" 정보 저장 | 로그인 정보 저장 |
| 만료 시점 | 쿠키 저장 시 만료일시 설정 가능 (브라우져 종료시도 유지 가능) | 다음 조건 중 하나가 만족될 경우 만료 1. 브라우저 종료 시 2. 로그아웃 3. 유지 기간 내 재요청이 없을 경우 |
| 용량 제한 | 브라우져 별로 다름(크롬 기준) - 하나의 도메인 당 180개 - 하나의 쿠키 당 4KB(=4096byte) | 개수 제한 없음 (단, 세션 저장소 크기 이상 저장 불가능) |
| 보안 | 취약 (클라이언트에서 쿠키 정보를 쉽게 변경, 삭제 및 가로채기 당할 수 있음) | 비교적 안전 (서버에 저장되기 때문에 상대적으로 안전) |
회원가입과 로그인 기능
→ 스프링 시큐리티 프레임워크로 구현 (인증과 인가를 위한 기능들을 제공)
// 스프링 시큐리티
implementation 'org.springframework.boot:spring-boot-starter-security'
// Thymeleaf (뷰 템플릿 엔진) for 로그인 사용자 이름 표시
implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'스프링 시큐리티를 사용하기 위해서는 WebSecurityConfig 클래스를 만들어 프레임워크의 규칙을 따라줘야 한다.
❗ 실행하니 CSS가 적용되지 않는 에러 발생
검사 -> Network 통해 css 파일 확인
-> 스프링 시큐리티의 URL 허용 정책에 CSS파일이 통과되도록 변경
Enum 설정한 값만 허용
클래스 선언하듯 Enum 선언해서 허용할 값만 넣어주면 된다.
패스워드가 평문으로(=있는 그대로) 저장된다?!
암호화(Encryption)는 의무이다!!
→ 스프링 시큐리티에서 제공하며 권고되고 있는 'BCrypt' 해시 함수 사용
❗ 실행하니 SQL 에러 발생
h2가 USER 테이블명을 허용하지 않아서 생기는 에러
-> 테이블명을 USERS로 변경
Spring Security가 사용자가 요청을 보내면 Controller로 가기 전 인증/인가 처리한 후에 성공 시에만 Controller로 전달
- Spring Security의 로그인 처리 과정
인증 관리자가 ID만 전달하면 서비스가 DB에서 조회하고 없으면 에러, 있으면 조회된 객체를 소유한 UserDetails 객체 생성 후 반환
-> ID와 PW 비교 + 인가 과정
UserDetails Service는 사실 인터페이스!
인증/인가 성공 시에만 Controller에게 회원 정보 (UserDetails) 전달
1. UserDetailsService 인터페이스
2. UserDetails 인터페이스
인터페이스로 구현해주면 스프링 시큐리티가 알아서 해준다.
로그아웃은 html에서 설정한 logout url을 시큐리티 설정에 넣어주면 된다.
회원과 관심 상품 정보를 연결하기 위해 Product에 회원 ID를 함께 저장하도록 한다.
관리자의 경우 Thymeleaf를 이용하여 서버에 admin값이 전달될 경우, 특정 id를 가진 div를 나타나게 하고, 그에 따라 url을 다르게 주어 get api를 각각 지정해준다.
Thymeleaf 기본 문법
타임리프 if else if else 조건식
SAVE 💾
심화반은 아무래도 진도가 더디게 나간다... 빠릿빠릿하게 하고 복습하려는데 어렵다😢
