Notice
Recent Posts
Recent Comments
Link
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 |
Tags
- interface
- RefreshToken
- 낙관적 락 롤백
- ObjectOptimisticLockingFailureException 처리
- ObjectOptimisticLockingFailureException
- 알고리즘
- redissonlock aop
- spring aop
- jpa
- DI
- multimodule testcontainers
- springsecurity
- aop
- 우아한 테크러닝
- kotest testcontainers
- Invalid property 'principal.username' of bean class
- @transactional
- 백준
- OptimisticLock
- TestContainers
- 형상관리
- AccessToken
- spring DI
- Spring Cloud Gateway
- java
- 멀티모듈 테스트컨테이너
- 낙관적 락 재시도
- 소수찾기 java
- S3
- netty
Archives
- Today
- Total
목록refresh 요청 (1)
조급하면 모래성이 될뿐
HttpOnly 쿠키로 토큰 관리 & 재발급 로직 구현
결론 - accessToken, refreshToken 모두 httpOnly 쿠키로 응답했다. (XSS 공격 방지) - 하지만 refreshToken을 통한 재발급 로직을 구현하기 위해서 httpOnly옵션의 accessToken 쿠키는 서버에서 추가적으로 신경 써주어야 한다. (FE팀에서 조차 accessToken에 접근할 수 없기 때문에 토큰 만료시점을 알 수 없다..) 장점 - XSS 공격 방지할 수 있음. 단점 - 쿠키 관리신경 써야 함 - 서버 로직이 복잡해질 수 있음 (비교적..) 직면한 문제 1 accessToken 쿠키 만료시간. 처음에는 accessToken 쿠키 만료시간을 JWT와 동일하게 주었다. 프론트에서는 토큰 만료 여부를 서버응답에 의존하기 때문에 쿠키가 사라지게 되면 서버에서는..
TroubleShooting/Yapp
2023. 8. 7. 02:57