Quartz 4

family-request-service

4 min readBohdan Derkach

family-request-service

Family API clients

Модулі відправки запитів до партнерського API всередині кожного Family-сервісу. Це не один універсальний class для всіх transport-ів.

У family-golden:

  • PartnerApiModule — transport і session infrastructure для партнерського API;
  • AdminApiService — явні admin-операції; зараз реалізовано login();
  • OfficialApiClient — HTTP login, parsing відповіді та отримання JSESSIONID;
  • OfficialSessionStore — зберігання JSESSIONID у Redis.

GWT transport додаємо окремо лише тоді, коли переносимо операцію, якої немає в Official API. Перелік наявних Golden-запитів зафіксований у family-golden/src/admins/golden-partner-api-audit.md.

Задача

  1. Отримати сформований HTTP або GraphQL request та контекст авторизації: admin або TU.
  2. Знайти credentials і актуальну session для цього контексту.
  3. За потреби виконати login або refresh.
  4. Додати до запиту потрібні cookies або token і відправити його партнеру.
  5. Зберегти оновлені cookies/tokens.
  6. При помилці авторизації оновити session і один раз повторити запит.

Кожен partner API має власний список операцій і типізовані методи. Бізнес-модулі викликають ці методи, а не передають сирі command, URL або body.

Admin: поточна авторизація

Golden

  • Credentials: числовий id_api і password.
  • Простий AgencyHelper приймає login/pass у кожному запиті й не використовує збережену session.
  • GWT RPC потребує JSESSIONID і keyD. keyD завантажується з актуального JS-модуля Golden; це технічний ключ GWT, а не credentials.
  • Новий Official API виконує команду login, отримує JSESSIONID і використовує її для наступних команд.
  • У новому Family-сервісі session зберігається в Redis за golden:official:session:admin:{login}. При втраті session виконується login і один retry.
  • Поточна перевірка credentials завжди робить новий login. Кешована session не може підтвердити новий пароль.
  • GWT лишається окремим legacy transport тільки для операцій, яких немає в Official API.

Prime

  • Credentials: email і password; login-запит також передає порожню captcha.
  • Login повертає result, refreshToken і cookies. Поточна реалізація використовує cookies, а refreshToken не зберігає і не використовує.
  • Cookies зберігаються в Redis як cookie::{email} з TTL 10 хвилин і додаються до кожного запиту.
  • При 401 сервіс повторно читає адмінку за email, виконує login і один раз повторює запит.

Chathouse

  • Credentials: secret_id і secret_key.
  • Login повертає access_token і expires_in; cookies не використовуються.
  • Token зберігається в Redis як token::{adminId} з TTL expires_in і передається як Authorization: Bearer <token>.
  • API має окремий /refresh. Поточний код уміє робити refresh перед завершенням token, але для admin token не записує expires_at; після зникнення token із Redis фактично виконується новий login.

Udate

  • Credentials: email і password; login-запит також передає порожню captcha.
  • Login повертає cookie token. Інші cookies із відповіді не зберігаються.
  • Cookie зберігається в Redis як cookie::{adminId} з TTL 10 днів і додається до кожного REST або GraphQL-запиту.
  • Окремий refresh у поточній реалізації не використовується. Якщо cookie відсутня, REST повернув 401 або GraphQL повернув unauthorized, сервіс повторно виконує login і повторює запит.
  • Після першого login запит CurrentUser перевіряє адмінку та повертає її ulid і legacyId.

TU: поточна авторизація

Golden

  • Credentials: числовий id_api і password самої TU.
  • Поточний login викликає usermodule/services/login, отримує cookies і зберігає їх у Redis як cookie::{ladyId_api} з TTL 24 години.
  • Наступні HTTP/GWT-запити додають збережені cookies. Для GWT RPC також використовуються keyAc/keyD.
  • При Access denied, завершеній session або іншій session-помилці сервіс повторно логінить TU і один раз повторює запит.
  • Нові workspace-запити через Official API використовують login/pass → JSESSIONID. У Family-сервісі session зберігатиметься в Redis за golden:official:session:tu:{login}.

Prime

  • Credentials: email, password і referral_code; login-запит також передає порожню captcha.
  • Login повертає result, idUser, refreshToken і cookies. Поточна реалізація використовує cookies, а refreshToken не використовує.
  • Cookies зберігаються в Redis як cookie::{ladyMongoId} з TTL 10 хвилин і додаються до HTTP-запитів.
  • Cookie tld-token окремо дістається зі збережених cookies для chat/media transport.
  • При 401 сервіс читає TU з БД, повторює login і один раз повторює запит.

Chathouse

  • Credentials TU: email і password. Режим оператора додатково потребує останній auth_code; режим supervisor передає is_admin=true без auth code.
  • Login повертає access_token і expires_in. Token разом з розрахованим expires_at зберігається в Redis із TTL expires_in.
  • Для operator session ключ має вигляд token::{ladyMongoId}::operator, для supervisor session — token::{ladyMongoId}.
  • Запити передають Authorization: Bearer <token>. Якщо до завершення token лишилося менше п’яти хвилин, виконується /refresh.
  • Якщо login повернув 401, поточний код через admin API встановлює партнеру password із нашої БД і повторює login.

Udate

  • TU не має власних credentials і не логіниться напряму.
  • Кожна активна TU призначається на suboperator. Запити від її імені виконуються через credentials і session цього suboperator.
  • Suboperator логіниться через email/password, отримує cookie token, яка зберігається в Redis як cookie::{suboperatorId} з TTL 10 днів.
  • Якщо cookie відсутня, REST повернув 401 або GraphQL повернув unauthorized, виконується повторний login і retry запиту.
  • Якщо credentials suboperator не збігаються, поточний production-flow змінює його password через admin API та повторює login.

Заповнити

  • Перевірити, чи JSESSIONID нового Official login приймається старим GWT RPC.
  • Інтеграційно перевірити перенесені GWT-операції з валідною адмінкою.
  • При перенесенні наступних операцій доповнювати каталог family-golden/src/partner-api/README.md.

Graph View

Backlinks