メインコンテンツまでスキップ
バージョン: 0.13.0 (Previous)

📍 Location

Location は、階層化された位置情報ツリーを提供します：公開された読み取りと、locationService 経由の管理者のみの作成・更新・安全な削除。

ここから始める​

identities と locations で locationService をマウントします。Bearer がデフォルトです。例ではそれを使用しています。locationService を支える defService は独自の JSON パーサーを登録するため、ホストレベルの express.json() はオプションですが、他のマウントされたルートもそれを必要とする場合に安全です。

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

const app = express();
app.use(express.json());
app.use(
  '/api',
  services.locationService(
    {identities, locations},
    {
      authSecrets: {authEncSecret: 'replace-me', authSignSecret: 'replace-me'},
      identity: {
        typeIds: {
          admin: 'admin-type-id',
          guest: 'guest-type-id',
          regular: 'regular-type-id',
        },
      },
    },
  ),
);
設定デフォルト / ソースの動作効果
dataStores.locations必須すべての Location block が読み書きします。
dataStores.identities型付き LocationServiceDataStore で必須；保護されたルートによって読み込まれる管理者バリデータが呼び出し元のアイデンティティを読み込みます。
authSecretsLocationServiceConfiguration で必須；保護されたルートのトークンアダプターによって読み込まれるアクセストークンアダプターがトークンを復号化し検証します。
identity.typeIds.admin保護されたルートで実行時に必須checkIdentityType(['admin']) は typeIds オブジェクトを要求し、その後 admin エントリと比較します。
authMode省略または 'bearer' は Authorization ヘッダーを使用'cookie' は accessToken を読み取ります。

クッキーモードには、サービスルーターの前にホストでインストールされた cookie-parser が必要です。ユーザーアクセストークンは常に指紋比較の対象となります；デフォルトの IP チェックは IP が異なる場合にのみユーザーエージェントの不一致を拒否します。

一般的なタスク​

タスク起点契約
位置情報を取得getLocationRoute公開 getLocationRoute with getLocationSchema
位置を一覧表示findLocationsRoute公開 findLocationsRoute with findLocationsSchema
階層ノードを作成createLocationFeaturecreateLocationFeature、createLocationRoute、createLocationSchema
ノードを変更または削除updateLocationRouteupdateLocationRoute または deleteLocationRoute

Bearer HTTP ワークフロー​

管理者は Authorization: Bearer <admin-access-token>、Content-Type: application/json、および createLocationSchema ボディで POST /api/locations を作成できます。createLocationRoute ��作成された位置情報を 201 で返します。提供された parentId は既存の位置を識別している必要があり；失敗は 404 です。

export API_BASE_URL='http://localhost:8080/api'
export ACCESS_TOKEN='replace-with-an-admin-access-token'

curl -X POST "$API_BASE_URL/locations" \
  -H "authorization: Bearer $ACCESS_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"code":"TOK","name":"Tokyo","type":"city"}'

authMode: 'cookie' に設定し、サービスルーターの前に cookie-parser を登録し、同じ createLocationSchema ボディと accessToken クッキーで POST /api/locations を送信します。createLocationRoute は引き続き管理者専用で、作成された位置情報を 201 で返します；クッキーが欠落している場合、選択された認証アダプターによって 401 で拒否されます。

export API_BASE_URL='http://localhost:8080/api'
export ACCESS_COOKIE='accessToken=replace-with-an-admin-access-token'

curl -X POST "$API_BASE_URL/locations" \
  -H "cookie: $ACCESS_COOKIE" \
  -H 'content-type: application/json' \
  -d '{"code":"TOK","name":"Tokyo","type":"city"}'

カスタム feature 合成​

この Bearer モードの断片は、上記のサービスマウントからの同じ identities、locations、および安全なプレースホルダー configuration を必要とします；dataStores は { identities, locations } です。ソースの順序で同じ 5 つのパブリック feature composer を合成します。POST /api/locations エンドポイントは createLocationRoute であり、createLocationSchema を検証し、管理者に 201 を返し、呼び出し人が認証されていないか管理者でない場合に 401 または 403 を返します。

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

const router = primitives.defService(
  partial(
    primitives.compose(
      features.createLocationFeature,
      features.getLocationFeature,
      features.updateLocationFeature,
      features.deleteLocationFeature,
      features.findLocationsFeature,
    ),
    [{authenticate: utils.getBearerTokenInfo, configuration, dataStores}],
  ),
);
app.use('/api', router);

リファレンスマップ​

ページ目的
BlocksLocation の永続化、階層、削除操作。
Featuresサービスによってマウントされるスキーマからルートへの composer。
Routesエンドポイント、アクセス、応答契約。
Schemasリクエスト検証契約。
Validators共有認証と管理者チェック。

関連モジュール​

Location service はサービス設定を定義します。Common validators は管理者アクセスを定義します。Auth utilities と cookie utilities は転送動作を定義します。