전체 글 493

google otp fast api 서버 적용

이번 포스팅에서는 사용자 인증 보안을 강화하기 위해 google otp 를 적용하는 과정을 포스팅하려고 합니다. 먼저 google otp의 동작과정을 바탕으로 비동기, 동기 처리를 해야하는지를 판단하는 과정을 기록하고, 이후 fast api에 google otp를 적용하는 과정을 설명하려고 합니다. 1. google otp의 동작과정 1) Set Up - server에서 otp 시크릿 키를 생성하고 google Authenticator 에 QR 코드를 생성합니다. 2) OTP Generation - user는 QR 코드를 바탕으로 키를 인증합니다. 이 과정은 서버가 아닌 다른 네트워크(다른 api 등)를 거치지 않고 local 적으로 동작합니다. 3) OTP Verification - user가 키를 인..

백엔드 2024.04.05

백준 14476 최대공약수 하나 빼기 python

최대공약수 뺴기 누적합 문제 해결 1. 왼쪽부터 차례로 누적 최대공약수를 구합니다. 2. 오른쪽부터 차례로 누적 최대공약수를 구합니다. [8, 12, 24, 36, 48] 예를 들어 index 0의 8이 빠지면 right_prefix_list[1]이 최대 공약수 입니다. index 1이 빠지면 left_prefix_list[1 - 1]과 right_prefix_list[1 + 1]의 최대 공약수가 전체의 최대 공약수입니다. 이 아이디어를 바탕으로 문제를 해결할 수 있습니다. 문제 오류 12는 빠진 수 8의 약수가 아니기 때문에 정답이 될 수 있다. -> 12는 8로 나누어 떨어지지 않기 때문에 정답이 될 수 있다. 예외 케이스 24는 8의 약수가 아니지만, 이것이 반례가 됩니다. 88%에서 막힌 이유 정..

CS/알고리즘 2024.04.03

spring과 fast api의 동시 요청 처리 차이점 정리

이번 포스팅에서는 spring boot와 fast api의 동기 처리 차이점을 정리하려고 합니다. Spring Boot 에서의 동시 요청 처리 Spring boot 에서는 multi Thread를 사용하여 동시 요청을 처리합니다. 이를 위해 Thread Pool이 존재하는데 그 안에 2개의 Thread가 있다고 가정하겠습니다. 만약 2개의 request가 동시에 온다면 어떻게 될까요? (I/O 관련된 request 1개와 다른 request 1개, CPU는 1개, 다른 Process는 없음) 먼저 I/O 관련 request가 0.0001초 빠르게 들어온 경우 1개의 Thread를 할당하고 애플리케이션 계층에서 OS 계층으로 전달됩니다. 이후 OS는 I/O device에 read/write 등을 요청하고 ..

카테고리 없음 2024.03.18

java spring vs python fast api 비교

이번 포스팅에서는 python fast api를 개발하기 전 python fast api와 java spring의 차이점에 대해 비교하며 공부한 것을 정리하려고 합니다. 1. 파이썬과 자바의 차이 자바는 컴파일 언어인 한편, 파이썬은 인터프리터 언어입니다. 컴파일 언어: 코드가 실행되기 전 컴파일러를 거쳣서 기계어로 모두 변환되어 실행되는 프로그래밍 언어 인터프리터 언어: 개발자가 작성한 코드를 기계어로 변환하는 과정없이 한줄씩 해석하여 명령을 바로 처리하는 프로그래밍 언어 2. java spring vs python fast API Fast API 1. 비동시성을 지원합니다. - 하나의 단계가 시작하면, 그 것이 끝날 때까지 기다리지 않고 다른 단계를 시작합니다. 2. type annotation을 지..

jwt refresh token 을 Redis로 리팩토링하기

기존에 db 테이블에 저장하여 조회하던 refresh Token을 Redis 인메모리 데이터 구조 저장소로 리팩토링하는 과정을 기록하는 포스팅입니다. 기존의 코드는 아래와 같습니다. 1. requestBody에 담긴 accessToken을 바탕으로 DB에서 refreshToken을 체크합니다 2. 만약 refreshToken이 valid하다면 accessToken을 발급합니다. DB에서 Redis로 리팩토링 하는 이유 1. refreshToken은 만료기간이 있는 token인데 DB에 저장할 필요가 있는지에 대한 의문이 들었습니다. -> DB는 또한 디스크의 읽기 쓰기와 관련되므로 api 응답속도도 느립니다. -> 인메모리를 사용하는 것으로 리팩토링하기 DB에서 Redis로 리팩토링 하는 과정 1. me..

백엔드/Spring 2024.03.04

spring security filter exception 처리 이슈 해결

jwt 토큰이 만료되었을 때의 응답을 처리하려고 하였습니다. ExpiredException을 받아 handling하려고 하였으나, global exception을 handling하기 위해 기존에 존재하던 @RestControllerAdvice는 security filter 단에서의 에러를 handling하지 못하였습니다. 이는 sevlet에 들어오기 전에 동작하는 것이었기 때문입니다.이에 이를 해결하는 과정을 포스팅합니다. spring security filter exception 해결 시도 1 아래의 사진에서 보듯 try catch 문을 통해 Exception이 발생한 경우 response writer를 사용해 응답을 반환해주려 하였습니다. 하지만 httpResponse에 wirte이 되지 않아 문제를..

IT/디버깅 2024.02.15

oneToMany가 연속적일 때 failed to lazily initialize a collection of role 에러 해결

member에 ticket이 1:N으로 있고 ticket에 1:N으로 file이 있는 연관관계에서 LazyLoadingException이 발생하여서 문제를 해결하는 과정을 기록합니다. nested fetch를 하려고 하였으나, org.hibernate.loader.MultipleBagFetchException이 발생하여 쿼리를 분리하던 과중에서 생긴 문제입니다. LazyLoading 문제상황 @Override public Member findMemberWithTicketsAndMemberTeamsByMemberId(Long memberId) { Member memberWithTickets = memberRepository.findMemberWithTicketsById(memberId) .orElseThr..

IT/디버깅 2024.01.28

jwt 사용 시 remember me 적용 안되는 이슈

spring version 3.xx 와 jwt를 사용해 login을 구현한 프로젝트에서 remember me 로 로그인 유지를 구현하려고 하는 중 remember me cookie가 생성되지 않아 이를 해결하는 과정을 포스팅합니다. 1. RememberMe가 동작하지 않는지 체크 spring security의 rememberMeAuthenicationFilter는 잘 동작하고 있음을 확인했습니다. 2. 다른 원인에 대한 고민 - Session Cookie SecurityConfig의 SessionCreationPoilicy.STATELESS 사용은 Session을 생성하지 않음을 확인하였고, 쿠키 기반인 remember-me 세션 쿠키가 생성되지 않는 것이 당연한 것이었습니다. 따라서 Security의 ..

IT/디버깅 2024.01.25

외장 톰켓에서 서버 실행해보기

이번 포스팅에서는 외장 톰켓에서 서버를 실행해본 과정에 대해 포스팅하려 합니다. 1. gradle 파일이 있는 곳으로 terminal 경로 설정하기 2. war 파일 생성하기 이후 build/libs에 war 파일이 생성되어 있음을 알 수 있습니다. WAR 파일은 Web Application Archive의 약자로 WAS에 배포할 때 사용하는 파일입니다. JAR 파일이 JVM 위에서 실행된다면, WAR 파일은 웹 어플리케이션 서버 WAS 위에서 실행됩니다. 3. apache-tomcat의 webapps에 war 파일을 넣습니다. 이 때 이름은 ROOT로 해야합니다. 4. apache-tomcat의 bin 폴더로 들어가 terminal에서 startup.bat(window 전용 명령어)를 실행해줍니다. S..

백엔드 2024.01.10

Alarm과 Alarm의 종류인 invitation 테이블을 분리할지에 대한 고민

기획적으로 알람에 invitation 알람, 새로운 ticket 생성에 대한 알람, FeedBack_Notice 알람 등 여러가지 알람이 존재한다. 하지만 Team invitation 을 따로 분리하자는 의견이 나왔다. invitation과 관련된 attribute가 많은데, 만약 Alarm에 합쳐지게 된다면, 다른 종류의 알람인 경우 관련 attribute 들 중 많은 것들이 null이 되기 때문이라는 것이 그 이유였다. 우리는 공통적인 부분을 Alarm 테이블로 만들고, 각각과 관련된 attribute를 따로 빼 상속하는 방식으로 데이터 테이블을 구성하기로 결정하였다.

카테고리 없음 2024.01.10
728x90