導入

Application side

アプリケーションで変えること

アプリケーションですることは、ヘッダーで届いたパスを tenant-pass に渡し、返ってきた認証情報をメモリにキャッシュすることです。そのうえで、次の 6 点を守ってください。

• 認証情報はメモリの中だけに置く

  認証情報を、ディスク、共有キャッシュ（Redis・memcached）、データベース、ログ、エラーレポート、メトリクスのラベルに書かないでください。

• refresh_at の時刻に取り直す

  refresh_at の時刻から、tenant-pass は次のウィンドウのパスワードを返します。早めに取り直しても害はありません（同じパスワードが返ります）。PostgreSQL では、refresh_at を実質の期限として扱ってください。

• 認証エラーなら repair を付けて 1 回だけ取り直す

  PostgreSQL の 28P01、MySQL の 1045、Redis の WRONGPASS を受けたら、"repair": true を付けて認証情報を取り直し、1 回だけ再接続します。それでも失敗したら、繰り返さずにエラーにします。

• 接続プールはテナントごとに分ける

  テナント A のプールをテナント B に使わないでください。使われなくなったテナントのプールは閉じて、認証情報をメモリから消します。

• テナントは応答から取る

  どのテナントかは、認証情報の応答の tenant から取ります。Host ヘッダーからは取らないでください。

• エラーの種類で扱いを分ける

  400・401・403 は、同じパスで何度試しても成功しない失敗です。429・503 は、間を空けてリトライしてかまいません。

# リクエストごと（疑似コード）
credential = cache.get(tenant)
if credential is None or now >= credential.refresh_at:
    credential = tenant_pass.fetch(pass)          # POST /v1/credentials
    cache.put(tenant, credential)
conn = connect(credential)
if conn failed with authentication error:
    credential = tenant_pass.fetch(pass, repair=True)
    cache.put(tenant, credential)
    conn = connect(credential)                    # 再接続は 1 回だけ。繰り返さない

パスのないリクエストには、テナントのデータに触れる権限がありません。そのようなリクエストはエラーにしてください。後から動く処理には ジョブチケット を使います。Go の実装例は、 クライアント連携 にあります。