Stabilize auth flow and profile images
This commit is contained in:
Codex
@@ -0,0 +1,305 @@
|
||||
# 2026-07-20 업무 인계 메모
|
||||
|
||||
작성 시각: 2026-07-20 KST
|
||||
|
||||
## 오늘 핵심 결론
|
||||
|
||||
- `tdc114plus` 앱과 로컬 `tdc114plus-auth:5001` 연결은 정상 확인했다.
|
||||
- 실기기 `adb reverse tcp:5001 tcp:5001`도 정상 확인했다.
|
||||
- 앱에서 `link/init` 호출 후 `pendingRef` 생성, 이후 `link/poll` 반복까지 서버 로그로 확인했다.
|
||||
- 즉 오늘 로그인 막힘의 핵심은 `앱 <-> 로컬 중계서버` 구간이 아니라 `Baron SSO 문자 링크 실제 발송/SMS 연계 구간`으로 판단했다.
|
||||
|
||||
## 오늘 확인한 최종 상태
|
||||
|
||||
### 1. 로컬 auth broker 상태
|
||||
|
||||
정상 확인값:
|
||||
|
||||
```bash
|
||||
curl -i --max-time 5 http://127.0.0.1:5001/health
|
||||
```
|
||||
|
||||
응답:
|
||||
|
||||
```json
|
||||
{"jwks":"ok","provider":"baron","status":"ok"}
|
||||
```
|
||||
|
||||
의미:
|
||||
|
||||
- 로컬 `tdc114plus-auth` 5001은 떠 있었다.
|
||||
- 최소한 health 기준으로는 죽어 있지 않았다.
|
||||
|
||||
### 2. 실기기 reverse 상태
|
||||
|
||||
사용자 확인 결과:
|
||||
|
||||
```text
|
||||
adb reverse --list
|
||||
UsbFfs tcp:5001 tcp:5001
|
||||
```
|
||||
|
||||
의미:
|
||||
|
||||
- 실기기에서 `127.0.0.1:5001`로 가는 호출은 PC 로컬 5001로 붙는 상태였다.
|
||||
- 따라서 실기기에서 auth broker 접속이 안 되는 상태는 아니었다.
|
||||
|
||||
### 3. 앱이 실제로 5001에 요청을 보내는지 확인
|
||||
|
||||
서버 로그에서 아래를 직접 확인했다.
|
||||
|
||||
```text
|
||||
linkInit body={"phoneNumber":"01091365338","device":{"platform":"android","appVersion":"0.1.0","deviceName":"android"}}
|
||||
```
|
||||
|
||||
그리고 이어서:
|
||||
|
||||
```text
|
||||
POST /api/v1/auth/link/init
|
||||
POST /api/v1/auth/link/poll
|
||||
```
|
||||
|
||||
반복 확인했다.
|
||||
|
||||
의미:
|
||||
|
||||
- 앱에서 로그인 버튼을 눌렀을 때 요청이 실제로 로컬 auth broker까지 도달했다.
|
||||
- `pendingRef` 생성도 정상 진행됐다.
|
||||
|
||||
### 4. 앱 내부 pending 상태 저장 확인
|
||||
|
||||
실기기 SharedPreferences에서 아래 항목을 직접 확인했다.
|
||||
|
||||
- `flutter.tdc114plus.auth.pending.ref`
|
||||
- `flutter.tdc114plus.auth.pending.expiresAt`
|
||||
|
||||
의미:
|
||||
|
||||
- 앱이 로그인 요청 직후 pending 상태를 저장하지 못하는 문제는 아니었다.
|
||||
- 앱 내부 상태 저장까지는 정상으로 봐도 된다.
|
||||
|
||||
## 오늘 발생한 실제 장애
|
||||
|
||||
현상:
|
||||
|
||||
- 앱에서는 `승인 대기 중` 화면으로 넘어간다.
|
||||
- 하지만 사용자 휴대폰에는 실제 문자 링크가 도착하지 않는다.
|
||||
- 재전송 시도 후에도 동일하다.
|
||||
|
||||
중요 판단:
|
||||
|
||||
- 앱 요청 실패 아님
|
||||
- 로컬 auth broker 연결 실패 아님
|
||||
- `adb reverse` 누락 문제 아님
|
||||
- 현재 가장 의심되는 구간은 Baron SSO 쪽 `문자 링크 실제 발송 처리` 또는 그 뒤 SMS 연계 구간이다.
|
||||
|
||||
## 오늘 중간에 있었던 혼선 정리
|
||||
|
||||
### 1. `auth_provider_unavailable`
|
||||
|
||||
한 시점에는 앱에 아래 문구가 보였다.
|
||||
|
||||
```text
|
||||
로그인 링크 요청 실패: auth_provider_unavailable
|
||||
```
|
||||
|
||||
이때 직접 확인한 사실:
|
||||
|
||||
- 같은 시각 `sso.hmac.kr /oidc/oauth2/auth`가 `502 Bad Gateway`를 반환하던 구간이 있었다.
|
||||
- 이후 재확인 시 다시 `302 Location: /login?login_challenge=...`로 정상 응답했다.
|
||||
|
||||
의미:
|
||||
|
||||
- Baron SSO upstream authorization 시작점이 한때 불안정했다.
|
||||
- 하지만 이후 복구된 뒤에도 최종적으로는 `문자 미수신` 문제가 남았다.
|
||||
|
||||
### 2. callback URL 혼선
|
||||
|
||||
아래 주소는 현재 직접 열면 `404 page not found`가 보인다.
|
||||
|
||||
```text
|
||||
https://114-auth.hmac.kr/api/v1/auth/oidc/callback
|
||||
```
|
||||
|
||||
정리:
|
||||
|
||||
- 이 URL은 브라우저에서 직접 여는 진입 URL이 아니라 OIDC 최종 code 수신용 callback 경로다.
|
||||
- 현재 `문자 미수신` 문제의 직접 원인으로 확정한 상태는 아니다.
|
||||
- 다만 라우트 정합성은 후속 점검 대상으로 계속 유지한다.
|
||||
|
||||
## 오늘 외부 전달용 요약
|
||||
|
||||
Baron SSO 개발자에게 전달할 핵심은 아래였다.
|
||||
|
||||
```text
|
||||
- 신규앱 -> 로컬 tdc114plus-auth(5001) 요청 정상
|
||||
- adb reverse 정상
|
||||
- auth 서버 로그상 link/init, pendingRef 생성, link/poll 반복 정상
|
||||
- 그런데 실제 문자 링크가 사용자 휴대폰에 도착하지 않음
|
||||
- 따라서 Baron SSO 쪽 문자 링크 실제 발송 처리 또는 SMS 연계 구간 확인 필요
|
||||
```
|
||||
|
||||
## 오늘 기준 남아 있는 작업
|
||||
|
||||
### 1. 문자 미수신 이슈 답변 대기
|
||||
|
||||
- Baron SSO 개발자 확인 결과를 받아야 한다.
|
||||
- 그 전까지는 앱/로컬 중계서버 쪽에서 더 고쳐도 문자 미수신 문제를 끝낼 수 없다.
|
||||
|
||||
### 2. 프로필 사진 route 상태 정리
|
||||
|
||||
현재 확인 상태:
|
||||
|
||||
- 앱은 `/api/v1/profile-image`를 먼저 시도한다.
|
||||
- 하지만 현재 5001 서버는 해당 route에 `404`를 반환한다.
|
||||
|
||||
의미:
|
||||
|
||||
- 사진 1순위/2순위/3순위 실기기 검증은 아직 시작 조건이 완전히 갖춰지지 않았다.
|
||||
|
||||
### 3. 로그인 화면 상태 문구 정리
|
||||
|
||||
관찰된 화면:
|
||||
|
||||
- 실패 문구
|
||||
- 승인 대기 박스
|
||||
- 재전송 카운트
|
||||
|
||||
이 조합이 시점별로 다르게 보였다.
|
||||
|
||||
후속 과제:
|
||||
|
||||
- 요청 시작 시 이전 에러 문구를 항상 지우는지
|
||||
- pending 복원 시 에러 상태를 같이 끌고 오지 않는지
|
||||
- 문자 미수신과는 별개로 화면 상태 표현이 꼬이지 않는지
|
||||
|
||||
## 외부 답변 대기 중 내부 진행 순서
|
||||
|
||||
문자 발송 구간 답변이 오기 전에도 아래 순서로는 내부 작업을 진행할 수 있다.
|
||||
|
||||
1. `tdc114plus-auth` 응답 메타데이터 정합성 재확인
|
||||
- `tenantSlug`, `tenantId`, `tenantName`, `department`, `grade`, `position`, `jobTitle`
|
||||
- 앱이 실제로 어떤 필드를 저장하고 소비하는지 확인
|
||||
|
||||
2. 로그인 화면 상태 표현 정리
|
||||
- `실패 문구`와 `승인 대기 UI`가 동시에 남지 않도록 정리
|
||||
- pending 복원 시 문구 초기화 조건 확인
|
||||
|
||||
3. `/api/v1/profile-image` route 복구 준비
|
||||
- 현재 앱 호출 형식 고정
|
||||
- auth 서버 route 부재 상태 문서화
|
||||
- 복구 시 필요한 응답 형태 확정
|
||||
|
||||
4. 프로필 사진 검증 대상 사용자 표 준비
|
||||
- NAVER WORKS 1순위 예상 사용자
|
||||
- UUID 이미지 2순위 예상 사용자
|
||||
- DEFAULT 3순위 예상 사용자
|
||||
|
||||
5. `baron-sso-tdc114plus-api` 제거 마이그레이션 표 세분화
|
||||
- 남은 기능이 진짜 필요한지
|
||||
- `tdc114plus-auth`에 흡수할지
|
||||
- 완전히 제거할지 분류
|
||||
|
||||
## 2026-07-20 메타데이터 정합성 재확인 결과
|
||||
|
||||
확인 결과:
|
||||
|
||||
- `tdc114plus-auth`가 내보내는 사용자 메타데이터 JSON 키와
|
||||
- `tdc114plus` 앱이 저장/사용하는 JSON 키는 현재 서로 맞는다.
|
||||
|
||||
확인한 키:
|
||||
|
||||
- `tenantId`
|
||||
- `tenantName`
|
||||
- `tenantSlug`
|
||||
- `department`
|
||||
- `grade`
|
||||
- `position`
|
||||
- `jobTitle`
|
||||
|
||||
정리:
|
||||
|
||||
1. 중계서버 출력
|
||||
- `tdc114plus-auth/cmd/server/main.go`
|
||||
- `readUser(...)`가 위 항목들을 읽는다.
|
||||
- `issueAppSessionToken(...)`가 같은 키명으로 JWT `user` 클레임에 넣는다.
|
||||
|
||||
2. 앱 수신/저장
|
||||
- `app/lib/src/features/auth/domain/auth_models.dart`
|
||||
- `LoginUser.fromJson(...)`가 같은 키명으로 파싱한다.
|
||||
- `app/lib/src/features/auth/data/auth_session_store.dart`
|
||||
- 세션 저장 시 `response.user.toJson()` 그대로 SharedPreferences에 저장한다.
|
||||
|
||||
3. 앱 소비 위치
|
||||
- `app/lib/src/features/directory/presentation/directory_screen.dart`
|
||||
- `tenantSlug`가 있으면 초기 회사 선택에 바로 사용한다.
|
||||
- `tenantSlug`가 비어 있으면 조직도 조회 fallback으로 현재 사용자 소속을 다시 찾는다.
|
||||
- `department`가 있으면 초기 부서 고정에도 바로 사용한다.
|
||||
- `profile_image_api_client.dart`에서도 `tenantSlug`/`tenantName`를 회사코드 추정에 사용한다.
|
||||
|
||||
현재 판단:
|
||||
|
||||
- 구조적 키 mismatch 문제는 아니다.
|
||||
- 진짜 남은 위험은 `Baron upstream 응답에서 값이 비어 들어오는 경우`다.
|
||||
- 특히 `tenantSlug`가 비면 앱은 fallback으로 버티지만, 초기 선택과 사진 1차 lookup 정확도는 떨어질 수 있다.
|
||||
|
||||
## 2026-07-20 프로필 사진 검증 대상 표
|
||||
|
||||
현재 문서와 과거 실검증 이력을 기준으로, source별 우선 확인 대상은 아래처럼 정리한다.
|
||||
|
||||
| 우선순위 | 예상 source | 사용자 | 근거 | 현재 상태 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 1순위 | `NAVER_WORKS` | `thlee3@samaneng.com` | 2026-07-15 네이버웍스 사진 조회 `HTTP 302` 확인 이력 | route 복구 후 실기기 재검증 필요 |
|
||||
| 2순위 | `BARON_UUID_R2` | `khkang@samaneng.com` | 2026-07-15 네이버웍스 사진 조회 `HTTP 404`, UUID 공개 이미지 fallback 이력 | route 복구 후 실기기 재검증 필요 |
|
||||
| 3순위 | `DEFAULT` | 미확정 | 실제 운영 사용자 중 `네이버웍스 없음 + UUID 이미지 없음` 샘플을 아직 확정하지 못함 | 샘플 대상 추가 선정 필요 |
|
||||
|
||||
현재 판단:
|
||||
|
||||
- 1순위와 2순위는 과거 실검증 이력이 있는 샘플이 이미 있다.
|
||||
- 3순위는 억지로 추정하지 말고, route 복구 후 실제 미보유 샘플을 한 명 확정하는 것이 안전하다.
|
||||
|
||||
## 2026-07-20 `/api/v1/profile-image` 복구 진행 결과
|
||||
|
||||
이번 복구에서 반영한 범위:
|
||||
|
||||
- `tdc114plus-auth`에 `GET /api/v1/profile-image` route를 다시 등록했다.
|
||||
- 현재 복구 로직은 아래 순서로 동작한다.
|
||||
1. `NAVER_WORKS`
|
||||
2. `BARON_UUID_R2`
|
||||
3. `DEFAULT`
|
||||
|
||||
구체 복구 내용:
|
||||
|
||||
- 네이버웍스 서비스 계정 env가 있으면 `GET /users/{email}/photo`의 `302/404` 규칙을 사용한다.
|
||||
- 네이버웍스에서 사진이 없으면 `org-context`에서 email 기준 Baron UUID를 찾는다.
|
||||
- UUID가 있으면 `https://baroncs.co.kr/employee_img/{uuid}.jpg` 공개 경로 존재 여부를 확인한다.
|
||||
- 둘 다 없으면 `found=false`, `source=DEFAULT`를 반환한다.
|
||||
|
||||
검증 결과:
|
||||
|
||||
- `go test ./cmd/server` 통과
|
||||
- 로컬 5001 재기동 완료
|
||||
- 무인증 호출 기준 이전 `404 page not found`가 아니라 아래처럼 바뀐 것을 확인했다.
|
||||
|
||||
```json
|
||||
{"error":"unauthorized","message":"앱 세션을 확인하세요."}
|
||||
```
|
||||
|
||||
현재 판단:
|
||||
|
||||
- route 자체는 현재 기동 서버에 복구됐다.
|
||||
- 즉 이전처럼 endpoint 자체가 없는 상태는 아니다.
|
||||
- 다음 실제 확인은 `로그인된 앱 세션` 상태에서 1순위/2순위/3순위 화면 검증으로 넘어가면 된다.
|
||||
|
||||
## 내일 또는 다음 작업 시작 시 우선 순서
|
||||
|
||||
1. `5001 health` 먼저 확인
|
||||
2. `adb reverse --list` 먼저 확인
|
||||
3. 앱에서 `link/init` 로그가 실제로 찍히는지 확인
|
||||
4. 문자 수신 여부를 먼저 확인
|
||||
5. 문자 미수신이면 앱 수정으로 우회하지 말고 Baron SSO 답변 상태부터 확인
|
||||
6. 문자 문제가 외부에서 정리되면 그 다음에 프로필 사진 검증으로 넘어간다
|
||||
|
||||
## 한 줄 요약
|
||||
|
||||
2026-07-20 기준 로그인 막힘의 핵심은 `앱이 요청을 못 보내는 문제`가 아니라 `요청은 정상인데 실제 문자 링크가 사용자에게 도착하지 않는 문제`다.
|
||||
Reference in New Issue
Block a user