機能の追加
本番環境の実際のシステムには、生成された CRUD エンドポイント以上のものが必要です。セキュリティ、権限、非同期処理、運用ジョブ、イベント発行、そして SaaS シナリオではテナントごとの分離が必要です。
Lino は、これらの機能を標準機能として追加します。各機能は、プロジェクトのメタデータを更新し、ソース コードを生成し、構成を追加し、バックエンド、フロントエンド、メッセージング、永続性を同じアーキテクチャに合わせて維持します。
認証と認可
認証機能は、Lino プロジェクトで使用されるセキュリティ基盤を追加して、API を保護し、ユーザーを識別し、操作へのアクセスを制御し、同じ権限を Blazor Web アプリと統合します。 次のコマンドでインストールされます。
lino feature auth add --service <ServiceName> --module <ModuleName>
コマンドは対話的に実行することもできます。 lino feature auth add。
正規ブランチは feature auth; CLI は次のようなエイリアスも公開します feature security と feature identity。
現在の Lino アーキテクチャでは、認証と認可は非同期メッセージングに依存しています。 理由は運用上の理由です。サービスとモジュールの権限は統合イベントによって同期されるため、セキュリティを追加する前にプロジェクトでメッセージングを有効にする必要があります。
魔法使いが求めるもの
CLI は、現在のプロジェクトを検証し、機能がまだインストールされていないかどうかを確認し、セキュリティ モジュールを作成する場所を尋ね、メインのトークン設定を要求します。
- サービス: セキュリティ リソースをホストするサービス。
- モジュール: 選択したサービスがモジュール型の場合のターゲット モジュール。
- アクセストークンの有効期間: 発行されたアクセス トークンの有効期間 (分単位)。
- リフレッシュトークンの有効期間: セッションの更新に使用されるトークンの有効期間。
-
ユーザー識別子の種類: ユーザー識別子として使用されるデータのタイプ (例:
int、longまたはGuid。
生成されたセキュリティモデル
確認後、Lino はプロジェクトのメタデータを更新し、セキュリティ構成値を作成し、ソース コード ファイルを生成し、必要なコマンドを実行します。 生成されたモデルには、次のような中心的なセキュリティ エンティティが含まれています。
Userは ID とプロフィール データを保存します。Roleおよびグループ アクセス ルールへの役割の関連付け。Permissionきめ細かな認可のための役割と権限間の関係。UserTokenリフレッシュトークンとトークンのライフサイクルを制御します。
この機能は、トークン署名用のシークレット、アクセス トークンとリフレッシュ トークンの有効期間など、セキュリティ構成に必要な情報も作成します。 機密値は、バージョン管理されたファイルに直接書き込まれるのではなく、AppHost ユーザー シークレットへのコマンドとして発行されます。
実行時の動作
API は JWT Bearer 認証を使用します。ユーザーはログインし、access token と refresh token を受け取り、Authorization: Bearer <token> ヘッダーを付けて API にリクエストを送信します。
バックエンドはトークンを検証し、ユーザー コンテキストをロードし、承認ルールをエンドポイントに適用します。
一般的なフローは単純です。エンドポイントまたは専用ページ経由でログインし、ID クレーム、ロール、権限を含む JWT を発行し、各リクエストでトークンを送信し、認証ミドルウェアを介して署名と有効期限を検証します。
Lino は、ポリシーと権限を使用して、詳細な承認を実装します。各アクションには、次のような特定の許可が必要な場合があります。 People.Read または People.Create;ポリシーは次のように構成できます。 AddAuthorization;エンドポイントは宣言することで保護できます。 .RequireAuthorization。
生成されたエンドポイントとページは、一貫してアクセス許可を使用します。バックエンド操作には権限が必要な場合がありますが、プロジェクトに Web アプリがある場合、生成された Blazor UI は権限の読み込み、ページの保護、使用できないアクションの非表示、ユーザー、ロール、権限、承認の画面の公開を行うことができます。
Background Jobがすでに有効になっている場合、Lino は、無効になったトークンや期限切れのトークンのメンテナンス ルーチンなど、ユーザー トークンに関連するジョブも追加します。
Background processingと Outbox
Background processingは、統合イベントの発行、古いレコードのクリーンアップ、期限切れのトークンの削除、通知の送信、レポートの生成、外部システムとの同期、スケジュールされたタスクの実行など、メインのリクエストとレスポンスのフローをブロックすべきではない作業を処理します。 Lino は、Background Job機能を通じてこの機能を追加します。
lino feature background-job add --service <ServiceName>
このコマンドは次のように実行することもできます。 lino feature background-job add インタラクティブに完了します。
CLI はエイリアスを次のように公開します job-scheduler と worker。
この機能は、トランザクション Outbox 標準によって登録されたメッセージを安全に公開することが主な役割であるため、プロジェクトでメッセージングが有効になっている必要があります。
魔法使いが求めるもの
- サービス: Background Job インフラストラクチャがインストールされるサービス。
- Background Jobライブラリ: ジョブの実行とスケジュールに使用される実装。現在生成されているインフラストラクチャは Hangfire を使用します。
- Outbox 処理: サービスがスケジューラによって処理されるイベントを登録するかどうかを定義します。
- CronOutboxメッセージ: 新しいメッセージ Outbox をチェックするために使用される範囲またはスケジュール式。
- バッチサイズ: サイクルごとに取得および処理される Outbox レコードの数。負荷、並列処理、リソース消費を制御します。
Hangfire インフラストラクチャ
Lino は、Hangfire の登録、その永続性の構成、ダッシュボードの公開、サービスで使用されるジョブのスケジュールに必要なインフラストラクチャを生成します。 生成された構成には、ジョブのスケジュール、Outbox メッセージの処理、スケジューラ ダッシュボードへのアクセス保護に必要な情報が含まれます。
生成されたソリューションでは、Hangfire スキーマとテーブルはアプリケーション データベース構成の一部です。 ダッシュボードは、開発および運用中に完了したジョブ、失敗したジョブ、スケジュールされたジョブ、および定期的なジョブを検査するのに役立ちます。
実際的な利点には、非同期タスクの信頼性の高い実行、組み込みの監視ダッシュボード、定期的なジョブまたはスケジュールされたジョブのサポート、データベース内のジョブの永続性などが含まれます。
トランザクション Outbox による処理
非同期統合の一貫性を確保するために、Lino はトランザクション Outbox パターンを使用します。 ビジネス ユース ケースでは、ドメインの変更が保持され、同じトランザクション内の Outbox テーブルに統合イベントが記録されます。 次に、Background Jobは Outbox テーブルを読み取り、これらのオプションがプロジェクトで選択されている場合、MassTransit を使用した RabbitMQ などの構成されたメッセージ バスを通じてイベントを発行します。
- コマンドはドメインの状態を変更し、この変更をトランザクションに保存します。
- ハンドラーは、統合イベント (注文の作成に関連するイベントなど) を Outbox に登録します。
- Hangfire ジョブは、未処理のメッセージのバッチをブロックし、これらのメッセージを処理中としてマークします。
- 各メッセージは逆シリアル化され、イベント バスによってパブリッシュされます。
- 成功したメッセージは処理済みとしてマークされます。失敗したメッセージには、後の分析または再試行戦略のためにエラー情報が保存されます。
その結果、データベースと記録されたイベント間のアトミック性、障害時にイベントが失われない信頼性、および複数のコンシューマがパブリッシュされたメッセージを処理できるスケーラビリティが実現します。
生成されたジョブには、すでに正常に処理された古い Outbox メッセージを削除し、処理中にスタックしたメッセージを解放するルーチンも含まれているため、アプリケーション障害後の永続的なロックのリスクが軽減されます。
認証がインストールされている場合、Background Job機能でトークン メンテナンス ジョブをホストすることもできるため、セキュリティ データを長期間にわたってクリーンな状態に保つことができます。
これらの追加機能により、Lino は、最新の実稼働アプリケーションの重要な要件に対して、堅牢なセキュリティ、きめ細かいアクセス制御、信頼性の高い非同期処理を提供します。
マルチテナンシー
マルチテナントは、各テナントの分離されたデータ、権限、構成を維持しながら、同じアプリケーションが複数のクライアント、組織、または環境にサービスを提供する必要がある場合に使用される機能です。 Lino では、tenant サポートが次のように追加されます。
lino feature tenant add --service <ServiceName> --module <ModuleName>
このコマンドは lino feature tenant add として対話的に実行することもできます。
CLI ブランチは、tenancy などのエイリアスも公開します。
前提条件
tenant サポートは、次の 2 つのアーキテクチャ機能に依存します。
- 認証と認可。ユーザーのアクセス、ロール、権限、トークンはテナントを認識する必要があるためです。
- メッセージング。tenantとユーザーの情報は統合イベントによって他のモジュールに伝播される可能性があるためです。
これらの前提条件が満たされていない場合、コマンドは拒否されます。また、この機能はプロジェクトごとに 1 回のみインストールできます。
何が生成されるのか
Lino は、テナントを一貫して管理するために必要なテナント モデル、構成、イベント、API 統合、およびフロントエンド リソースを作成します。
Tenantはテナント ID、名前、スラッグ、ステータス、分離モード、および接続文字列参照を保存します。TenantBrandingテナントごとに特定の視覚的動作のブランド データを保存します。TenantDomainホストまたはドメインをテナントにマッピングします。TenantStatusとIsolationModeテナントのライフサイクルとデータ分離オプションを定義します。- 生成された構成は、プロジェクトのテナント解決とデータ分離をサポートします。
tenant-awareセキュリティ
テナンシーにより、認証と認可の解釈方法が変わります。有効なトークンと権限は、現在のテナントのコンテキスト内で評価されます。あるテナントにアクセス権を持つユーザーが、別のテナントへのアクセス権を自動的に受け取ることはありません。 したがって、tenant サポートは、認証フロー、リフレッシュ トークンの動作、UI 用に生成されたアクセス許可および参照を更新します。
生成された Blazor アプリケーションでは、テナントと認証フローを管理するためのtenant-aware画面を追加できます。 バックエンドでは、生成されたエンドポイントは、構成されたホスト、スラッグ、またはルートの動作からテナント コンテキストを解決し、データと承認の決定にテナント識別子を適用できます。
データの分離と伝播
Lino は、エンティティがテナントごとに所有権を宣言できるようにすることで、tenant-awareドメイン モデリングをサポートします。 SaaS シナリオでは、これにより、共有モジュールが必要なテナントとユーザーの情報を引き続き受信しながら、ビジネス テーブルでテナント固有のデータを保存できるようになります。
生成されたアーキテクチャは、イベントと Outbox パターンを使用して、すべてのモジュールを元の ID テーブルまたはテナント テーブルに直接結合することなく、選択したテナントまたはユーザー データをモジュール間で伝播します。 これにより、モジュールの境界が明確に保たれ、同時に画面、API、権限、クエリはテナント コンテキストで動作し続けます。
tenancy を追加した後、影響を受けるサービスの移行を作成して適用し、生成されたシークレットと API キーを確認し、AppHost を実行して、少なくとも 2 つのテナントで検証して、データ、ユーザー、ロール、権限、ビジネス レコードが分離されていることを確認します。
- 分離を検証します。 別のテナントからのデータにアクセスしようとするテストを作成します。
- 権限を確認します。 ユーザーは、異なるテナントで異なる役割を持つことができます。
- クライアントを信頼しない。 ルート、ホスト、スラッグ、またはヘッダーによって通知されるテナントは、認証されたユーザーと互換性がある必要があります。