3

パーミッション/承認 (認証ではない) は分野横断的な問題だと思います。

Onion アーキテクチャまたは Hexagonal アーキテクチャでは、どこでパーミッションを実行する必要がありますか? 必要な許可の例は次のとおりです。

  • フロントエンドに返されるデータのフィルタリング (UI、API、またはその他)
  • ビジネス オペレーションがまったく実行可能であることの検証

理想的には、単一責任の原則により、ビジネス オペレーションを実行してデータを返すコードは、ユーザーのアクセス許可をまったく認識する必要がありません。その機能の実装は、ビジネス オペレーションを実行する方法、またはリポジトリやドメイン サービスにクエリを実行する方法を知っている必要があります。それだけです。

ビジネス操作を実行したり、データを返したりするクラスと同じインターフェースを実装するラッパー/ファサードは、このパーミッションを置く場所でしょうか? それとももっと良い方法がありますか？

また、ベスト プラクティスがロールではなくアクティビティごとのアクセス許可である場合、単にデータを返すことを目的とするサービスによってアクセス許可を実行する必要があると言うのは有効ですか?

4

2 に答える 2

2

アクセス チェックは、誰かがアクセス チェックをバイパスするサイド チャネルを見つける可能性を減らすために、操作を実行するコードのできるだけ近くに配置する必要があると主張する人もいるかもしれません。とはいえ、本番システムでアクセスチェックが常に行われることを保証するようなラッパークラスを使用できれば、それで問題ないと思います。

ビジネス オペレーションがまったく実行可能であることの検証

操作を実行できるかどうかを判断するアクセス チェックをラッパーに入れるのはごく自然なことだと思います。通常、ラッパー コードは、保護された関数に渡される引数を理解し、承認の決定を行うのに適した形式に変換する単純な接着剤です。

フロントエンドに返されるデータのフィルタリング (UI、API、またはその他)

これにより、呼び出し元のアクセス許可に基づいて、クエリの応答から行をフィルター処理することを意味していると想定しています。たとえば、部門の管理者が全員の給与を照会した場合、その管理者には、部下の給与にアクセスする権限がないため、部下の給与のみが返されます。

このタイプのフィルタリングについては、分野横断的な関心事としてそれを実装する方法を見つけたことがありません。ビジネス ロジックにフィルタリングを組み込むか、アクセス許可がないためにクエリの実行を単に拒否するモデルに戻りました。

私が直面した問題は、フィルタリングを有効にするには、セキュリティ コードが返されたデータを調べて、アクセス許可を関連付けることができる必要があるということです。単純なケースでこれを行うのはかなりの作業量のように思えますが、複雑なケースでは実に厄介です (複数のデータベース操作の結合であるデータ セットが返されることを想像してください)。

とはいえ、私はコンテンツ フィルタリングに反対しているわけではありません。私はそれに対する良い解決策を見たことがありません。

于 2015-06-14T02:46:21.510 に答える
0

アクティビティごとのアクセス許可は、承認 API によってチェックされているアクセス許可とアクティビティがある場所です。これは Roles and Permissions と同じであり、認可は、Role が認可されていると指定したビジネス オブジェクトに対して権限をチェックすることによって行われます。これにより柔軟性が得られます。修正されるのはパーミッションだけですが、パーミッションから完全に独立した DB で定義されたさまざまなロールを持つことができます。

承認ロジックを、表示用のオブジェクトを返すサービスおよびビジネス層から完全に分離する 1 つの方法は、カスタム承認属性を使用することです。これらの属性では、MVC コントローラーでアクションを実行するためにユーザーが必要とする権限を指定できます。

ユーザーがアクセス許可を持つビジネス オブジェクトを取得し、サービスまたはリポジトリを呼び出すときにそれらを入力として使用することは、承認ロジックをサービス ロジックから分離するための良い方法です。その例は次のようになります-私はユーザーxで、顧客y、t、g、およびlにアクセスできます-私の顧客のすべての注文を私に与えてください。

于 2015-06-17T16:21:00.727 に答える