일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- OptimisticLock
- springsecurity
- TestContainers
- DI
- S3
- interface
- ObjectOptimisticLockingFailureException 처리
- Spring Cloud Gateway
- spring aop
- redissonlock aop
- 멀티모듈 테스트컨테이너
- 우아한 테크러닝
- 형상관리
- 낙관적 락 롤백
- multimodule testcontainers
- ObjectOptimisticLockingFailureException
- AccessToken
- kotest testcontainers
- @transactional
- spring DI
- Invalid property 'principal.username' of bean class
- 알고리즘
- aop
- RefreshToken
- netty
- 낙관적 락 재시도
- 소수찾기 java
- 백준
- jpa
- java
- Today
- Total
목록분류 전체보기 (66)
조급하면 모래성이 될뿐
결론 - 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토큰을 만들어서..
Why? 프로젝트를 하면서 지역별로 현재 참여 가능한 게시글이 몇 개인지 응답하는 API를 구현해야 했다. 이 API의 응답은 지역별로 참여가능한 글의 개수를 확인하고, 검색 필터조건으로 사용하기 위함이었다. 다음과 같은 데이터가 있다면 id city province status 1 경기도 성남시 분당구 IN_PROGRESS 2 경기도 성남시 분당구 DONE 3 경기도 용인시 IN_PROGRESS 4 서울특별시 서초구 DONE 아래와 같은 정보를 만들어야 한다. 경기도: 2 성남시 분당구 1 용인시: 1 서울특별시: 0 서초구: 0 이 API의 응답은 자주 바뀌지 않고 고정적이다. 바뀌는 경우는 게시글 등록, 삭제, 상태가 변경되었을 때이다. 위 문제를 해결하기 위해서는 Board 테이블을 전체 조회하..