dsm-dms / dms-backend Goto Github PK

신입생들의 학번 명렬표 가 필요함

개발용으로 배치해 두었던 3001번 포트로 통신하던 트래픽을 제거하고, 80 포트로 모든 트래픽을 combine합니다.

apply를 계속 지켜본 결과 default는 잘 동작합니다.

dms-v2와 같은 느낌으로 MongoDB에 데이터베이스를 새로 만들고, 이를 바라보도록 한 상태에서 스키마를 재작성합니다.

외출 신청시간을 일요일 20:30 ~ 금요일 22:00 으로 제한

현재 Api 객체를 만들면서 prefix를 설정하고 있는데, Api 객체를 만든 이후 다음 라인에서 prefix를 설정하면 더 직관적이라는 것을 알고 있습니다. 따라서 해당 이슈에 대한 간단한 리팩토링을 진행합니다.

1. 연장신청 데이터 cleaner
2. 중복신청 데이터 cleaner(새로 작성)
3. 급식 파서
4. MongoDB to InfluxDB exporter

1. try - except로 Slacker 부분 예외처리로 감싸고, live 서버가 참조하는 데이터베이스에 누적되도록 수정
2. 문제 해결 후 배치

어플리케이션 측은 강제적인 업데이트가 미존재하므로, v1 API에 대한 테스트 케이스는 지속적으로 몰고 나가야할 필요가 있습니다.

• TCBase 리팩토링
• 테스트 코드 재작성

date = DateTimeField(
    required=True
)

가 있는 모델을 생성하면 date가 서버를 킨 시점으로 고정되는 문제

회원가입을 대기중인 학생과 완료 학생 리스팅 api

API v1과 v2를 상호 운용하기 위함입니다. 해당 작업이 끝나면, 데이터베이스에 관한 이슈는 모두 종료입니다.

프론트엔드 측에서 v2 API로 마이그레이션이 모두 진행되어 모든 클라이언트가 v2를 참조하면, API v1을 제거합니다.

암호화 관련 이슈 처리를 위해 ID만 검증하던 부분을 다시 ID/PW 모두 검증하기로 합니다.

기존에 사용하던 데이터베이스를 데이터베이스 v2로 마이그레이션하는 코드를 작성합니다.

DMS API version 2를 작성합니다.

Protocol

• application/x-www-form-urlencoded를 application/json으로 변경
• key name을 snake case에서 camel case로 변경

API Spec

• 학생 계정 삭제와 관리자 계정 삭제 API를 각각 DELETE /admin/account-control/student, DELETE /admin/account-control/admin으로 변경
• 관리자 계정 생성 API를 POST /admin/new-account에서 POST /admin/account-control/admin으로 변경

refresh token 컬렉션에 이제 거의 10K정도의 document가 들어가 있습니다(..) 이전부터 '개선해야겠다' 싶은 부분이긴 했는데, 토큰을 어떻게 보관하고 발급할지, 각 사용자 세션의 unique함을 어떻게 판단할지를 생각해내지 못해 계속 헤매다가 방법을 생각해내서 로직 개선을 진행하고자 합니다.

한 사용자-한 디바이스를 묶어(userid + user-agent) unique를 판단한다는 것을 전제로 합니다.

개선 후의 로직

1. 사용자가 로그인 요청
2. 로그인에 성공하는 경우, access token과 refresh token에 해당하는 토큰 identity를 만들고, 사용자는 ID와 user agent를 더해 token용 ID를 만듭니다.
3. access token model과 refresh token model 각각에 identity와 함께 사용자 ID를 저장합니다.

해결 가능한 문제

1. 이미 발급된 Token의 expire를 건드릴 수가 없어 로그아웃 처리가 어려웠는데, 단지 토큰 identity를 모델에서 지우는 것만으로 로그인 처리가 가능해 집니다.
2. 어느 사용자가 한 디바이스에서 여러 번의 로그인을 수행하더라도, 실제로 활성화되는 토큰은 단 하나 뿐이라 논리적으로 일관성을 지킬 수 있게 됩니다.
3. Token이 계속해서 쌓여 생기는 문제를 해결할 수 있습니다.(사실 token을 모델에 계속 쌓는 형태는 session이랑 다를 바가 없습니다..)

상호 운용

앞으로의 토큰 발급

위에서 설명한 로직으로 진행합니다. 단, 그 전에 RefreshTokenModel에 user-agent 필드를 추가하고, AccessTokenModel을 새로 추가해 주어야 합니다.

이미 로그인되어 있는 사용자?

이들은 token identity가 각자의 ID입니다. 따라서 view function에 감싸진 auth_required같은 데코레이터에서도 단지 ID로 쿼리해서 user 객체를 가져오고 있습니다.

해당 로직은 유지하되, 새로운 로직이 적용된 이후 토큰을 발급받은 사용자를 위한 로직을 다음과 같이 구성합니다.

1. AccessTokenModel에 token identity로 쿼리
2. 결과가 존재한다면, 해당 모델에 존재하는 ReferenceField인 user 객체를 g 객체에 assign

Refresh 로직은 다음과 같습니다.

1. RefreshTokenModel에 token identity로 쿼리
2. 결과가 존재한다면, 해당 모델에 존재하는 user 객체와 user-agent를 통해 access token 발급 로직을 수행

Live로 돌고 있는 서버가 참조하는 'dms' 데이터베이스의 컬렉션 중, 이전에는 사용하다가 데이터베이스 구조를 바꾸며 현재는 쓸모 없는(CRUD가 진행되지 않는) 컬렉션이 있습니다. 제거 작업이 필요합니다.