일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- ObjectOptimisticLockingFailureException
- TestContainers
- spring DI
- 소수찾기 java
- spring aop
- java
- aop
- multimodule testcontainers
- OptimisticLock
- Spring Cloud Gateway
- 우아한 테크러닝
- 낙관적 락 재시도
- @transactional
- redissonlock aop
- springsecurity
- DI
- jpa
- 백준
- 멀티모듈 테스트컨테이너
- S3
- ObjectOptimisticLockingFailureException 처리
- AccessToken
- 알고리즘
- netty
- RefreshToken
- kotest testcontainers
- interface
- Invalid property 'principal.username' of bean class
- 형상관리
- 낙관적 락 롤백
- Today
- Total
목록TroubleShooting/Yapp (4)
조급하면 모래성이 될뿐
https://tech.kakaopay.com/post/overcome-spring-aop-with-kotlin/#overcome-with-kotlin--spring-context Kotlin으로 Spring AOP 극복하기! | 카카오페이 기술 블로그 Kotlin의 문법적 기능을 사용해서 Spring AOP 아쉬운 점을 극복한 경험을 공유합니다. tech.kakaopay.com 위 글을 읽고 프로젝트에 적용한 AOP 코드를 개선해보고 싶다는 생각이 들었다. 개선하고 싶은 코드는 동시성 처리를 위한 Redisson Lock 처리 코드이다. 정리 - 동시성 처리를 위해 적용한 AOP 코드를 KotlinAOP로 변경해 보았다. - 두 방식 모두 장, 단점이 있는 것 같다. - Spring AOP는 익숙하기 ..
결론 - accessToken, refreshToken 모두 httpOnly 쿠키로 응답했다. (XSS 공격 방지) - 하지만 refreshToken을 통한 재발급 로직을 구현하기 위해서 httpOnly옵션의 accessToken 쿠키는 서버에서 추가적으로 신경 써주어야 한다. (FE팀에서 조차 accessToken에 접근할 수 없기 때문에 토큰 만료시점을 알 수 없다..) 장점 - XSS 공격 방지할 수 있음. 단점 - 쿠키 관리신경 써야 함 - 서버 로직이 복잡해질 수 있음 (비교적..) 직면한 문제 1 accessToken 쿠키 만료시간. 처음에는 accessToken 쿠키 만료시간을 JWT와 동일하게 주었다. 프론트에서는 토큰 만료 여부를 서버응답에 의존하기 때문에 쿠키가 사라지게 되면 서버에서는..
현재 진행하는 프로젝트에서는 소셜로그인을 사용하지 않는다. 자체 인증시스템이 필요했고 JWT를 적용했다. 기존의 인증방식 기존의 쿠키나 세션방식은 서버 또는 클라이언트에 유저 정보를 저장하여 인증을 수행한다. 쿠키는 웹 브라우저에 저장하기 때문에 비교적 쉽게 탈취당할 수 있다. 세션은 다중서버구현 시 정합성을 보장할 수 없다. A클라이언트의 요청을 S1서버에서 인증했을 때, 두 번째 요청이 S2로 전송되면 S2세션에는 A유저의 정보를 모르기 때문에 인증이 되지 않는다. (스티키 세션, 세션 클러스터링, 메모리 디비를 사용해 해결할 순 있다.) JWT JWT는 RFC 7519 버전에 만들어진 약속이다. JWT의 핵심은 서명된 토큰이라는 것이다. 쉽게 서버에서 지정한 SecretKey로 JWT토큰을 만들어서..