バージョン: 0.13.0 (Previous)

🆔 アイデンティティ

アイデンティティは services.identitiesService を通じて、管理者専用のアイデンティティレコードのリスト取得、取得、更新、削除、ロック、解除用のHTTPエンドポイントを提供します。

ここから始める

services.identitiesService をAPIプレフィックスの下にマウントします。サービスの defService ルーターは自身で express.json() をインストールします；Cookieモードの場合、ホストはサービスルーターの前に cookie-parser を登録することも必要です。全ての6つのルートには有効な管理者アクセストークンが必要なので、identities コレクション、認証シークレット、および設定されたアイデンティティ型IDを提供します。

import express from 'express';
import cookieParser from 'cookie-parser';
import { services } from '@nodeblocks/backend-sdk';

const app = express();
app.use(cookieParser()); // authMode が 'cookie' の場合にのみ必要。
app.use(
  '/api',
  services.identitiesService(
    { identities },
    {
      authSecrets: {
        authEncSecret: process.env.AUTH_ENC_SECRET!,
        authSignSecret: process.env.AUTH_SIGN_SECRET!,
      },
      authMode: 'bearer',
      identity: {
        typeIds: {
          admin: 'administrator-type-id',
          guest: 'guest-type-id',
          regular: 'regular-type-id',
        },
      },
    },
  ),
);

設定	デフォルト/ソースの動作	効果
`dataStores.identities`	必須	アイデンティティブロックと `checkIdentityType(['admin'])` によって使用される。
`authSecrets.authEncSecret`、`authSecrets.authSignSecret`	必須	選択されたトークン認証アダプタによって使用される。
`authMode`	省略または `'bearer'` は Authorization ヘッダーアダプタを使用；`'cookie'` は `request.cookies.accessToken` を使用	保護されたルートのアクセストークンのトランスポートを選択する。
`identity.typeIds.admin`	ランタイム時に必須	`checkIdentityType(['admin'])` は呼び出し元の読み込まれた `typeId` とこの値を比較する。
`identity.typeIds.guest`、`identity.typeIds.regular`	提供された場合、宣言された `typeIds` オブジェクトによって必須	これらのアイデンティティルートでは使用されない。

全てのルートは最初に isAuthenticated() を実行し、次に checkIdentityType(['admin']) を実行します。2番目のバリデーターは呼び出し元のアイデンティティの読み込みと認可をしながら再度認証を行います；アイデンティティバリデーターを参照してください。

よくあるタスク

タスク	該当ドキュメント	コントラクト
アイデンティティのリストまたはフィルタリング	`findIdentitiesFeature`	`findIdentitiesFeature`、`findIdentitySchema`、および `findIdentitiesRoute`
1つのアイデンティティの取得または更新	`getIdentityRoute`	`getIdentityRoute`、`updateIdentitySchema`、および `updateIdentityRoute`
アイデンティティのロック、解除、または削除	`lockIdentityRoute`	`lockIdentityRoute`、`unlockIdentityRoute`、および `deleteIdentityRoute`
アイデンティティデータベースヘルパーを再利用する	アイデンティティブロック	アイデンティティブロック

Bearer HTTPワークフロー

authMode を省略または 'bearer' に設定する場合、Authorization ヘッダーに管理者アクセストークンを送信します。

ACCESS_TOKEN='管理者のアクセストークンに置き換えてください'
curl "https://api.example.test/api/identities?name=Example&page=1&limit=20" \
  -H "Authorization: Bearer $ACCESS_TOKEN"

成功時、findIdentitiesRoute はデフォルトの 200 JSON配列を返します（password と MongoDB _id を削除）。非管理者呼び出し元は 403 で拒否されます；トークン設定の欠落または無効なトークンも共有バリデーターコントラクト経由で失敗します。

authMode: 'cookie' の場合、サービスルーターの前に cookie-parser を登録し、accessToken Cookieを送信します。

IDENTITY_ID='identity-demo-001'
ACCESS_TOKEN='管理者のアクセストークンに置き換えてください'
curl -i -X POST "https://api.example.test/api/identities/$IDENTITY_ID/lock" \
  -H "Cookie: accessToken=$ACCESS_TOKEN"

成功時、lockIdentityRoute はボディなしの 204 を返します。accessToken Cookie の欠落は 401 を生成します；認証には依然として設定された管理者アイデンティティ型が必要です。

カスタム機能合成

このフラグメントは意図的にアイデンティティ取得とロックのみをマウントします。同じアイデンティティデータストア、認証アダプタ、および設定コンテキストを供給する必要があります。

import { partial } from 'ramda';
import { features, primitives, utils } from '@nodeblocks/backend-sdk';

const identityFeatureComposer = primitives.compose(
  features.getIdentityFeature,
  features.lockIdentityFeature,
);
const identityRouter = primitives.defService(
  partial(identityFeatureComposer, [{
    authenticate: utils.getBearerTokenInfo,
    configuration: {
      authSecrets,
      identity: { typeIds },
    },
    dataStores: { identities },
  }]),
);

app.use('/api', identityRouter);

リファレンスマップ

ページ	目的
ブロック	アイデンティティデータベース操作、状態ペイロードビルダー、および削除ターミネーター
機能	サービスによってマウントされるスキーマからルートへのコンポーザー
ルート	エンドポイントメソッド、パス、アクセスルール、ステータス、およびパイプライン
スキーマ	リクエストコントラクトと共有の `identityId` パラメーター
バリデーター	全てのアイデンティティルートによって使用される共有認証と管理者チェック

アイデンティティには handlers.md がありません；ルーターは再利用可能なブロックを直接合成します。

ここから始める​

よくあるタスク​

Bearer HTTPワークフロー​

Cookie HTTPワークフロー​

カスタム機能合成​

リファレンスマップ​

関連モジュール​

ここから始める

よくあるタスク

Bearer HTTPワークフロー

Cookie HTTPワークフロー

カスタム機能合成

リファレンスマップ

関連モジュール