web-dev-qa-db-ja.com

REST API-エンティティに対してアクションが許可されているかどうかを確認します

同僚に質問に画像を投稿するための十分な評判がないため、この質問をしています

通常の開発中に、REST APIの不足が見つかりました。エンティティを次のようにUIに表示します。これにより、上部のボタンはいわゆるアクションと呼ばれます。

画像には、アクションとして機能するボタンと剣道グリッド/テーブルコンポーネントが表示されます。エントリReportExecutionJobがテーブルで選択され、その選択に対してアクションを使用できるようになります。

詳細

アクション自体は一般的です。それは多くのものやメタデータを知らないだけでなく、特定のオブジェクトに対してタスクを実行するだけです。たとえば、deleteと呼ばれるアクションを追加することができ、それに与えたエンティティを削除しようとします。

特定のエンティティで許可されているアクションを通知する、ユーザー許可システムと分離された一般許可システムがあります。

例：エンティティXで削除アクションを実行する権限がある可能性がありますが、同じインスタンスでは、ユーザーはアクションを呼び出す権限をまったく持っていない可能性があります。

問題

たとえば、ReportExecutionJobが選択されている場合、選択されたエンティティに対してアクション（一時停止など）が通常許可されているかどうかをチェックしますFrontEndで。その後バックエンドは、ビジネスロジックを保持して、ユーザーが選択したエントリに対してそのアクションを呼び出す権限を持っているかどうかを確認します。

その結果、2つの場所で1つのトピック/問題を処理します。

質問

これを最も効率的で安全な方法で行うにはいくつかの質問があります。

応答のエンティティの一部として情報（エンティティで許可、ユーザーで許可）を取得することを提案しますか？

アクション自体からロードする必要があります（そのため、何かが選択されると、バックグラウンドでリクエストが実行され、エンティティでアクションが有効または無効になっていて、ユーザーが許可されている場合に結果が得られます）

ベストプラクティスの方法または推奨事項はありますか？

そして、私の同僚は、これらすべてをいつ行うべきかという疑問を持っています。テーブルのエントリを選択するとき、またはアクションを実行しようとするとき、ページをロードするかどうか。

javajavascriptrestapi-designpermissions
3
Nico

これを処理する方法はいくつかありますが、ユーザーエクスペリエンスの理由から、新しいドロップダウンアイテムが選択される前に、クライアントに関する情報を取得することが理想的です。

そこから、特定のアイテムが許可されるアクションをフロントエンドにどのように伝えるかは実際にあなた次第ですが、かなりクリーンだと私が見た1つの方法は、HATEOAS（アプリケーション状態のエンジンとしてのハイパーテキスト）を使用することです。

その場合、サーバーからリソースをフェッチするたびに、すべてのデータが含まれますが、サポートされている他のアクションへのリンクの形でメタデータも含まれます。これは、現在のユーザーに対してサポートされている他のアクションをクライアントに通知する簡単な方法であり、クライアントはどのボタンを表示または有効にするかを理解できます。

2
Paul
  1. ユーザーはコマンドを実行する権限を持っていますか

参考：現在、BEの権限システムによってこれを解決する予定です。このシステムでは、アクション（ボタン）がレンダリングされない場合に、ユーザーに権限が割り当てられているかどうかを確認します。クライアントはrestを呼び出し、割り当てられたすべての権限を取得し、ユーザーが実行できることまたは実行できないことを確認できます（すべての権限はクライアントの起動時に転送されます）。

  1. ジェネリックエンティティXはジェネリックアクションを許可しますか

私はこれをクライアントにハードコアし、私が答えをすでに知っていることを尋ねるために往復を節約します。

これが現在行っていることです。チェックはBEとFEでコーディングされます。また、HATEOSに対するあなたの主張にも完全に同意します。

BEはメタ情報をデータに追加します

if (entity.field === "State 10" && otherEntity.locked = false ) {....}のようなチェックのため、businesslogicがクライアントに転送されるのを恐れます

私たちの恐怖は私たちが次のことをすることです：

  • 自分を繰り返す
  • ロジックチェックを調整するには、FEおよびBE開発者が必要です。
  • BusinesslogicはFEに転送できます/転送されます
  • これらのメタデータをデータに追加すると時間がかかります（以下を参照）

（HATEOSと同様に）メタデータをエンティティに追加すると、次のようになります。

[ 
  { 
    _actions: [ xy_allowed: true ], 
    name: "ReportExecutionJob", 
    otherFields: ...
  },
.... 
]

すべてのデータ行でアクションが許可されているかどうかを確認する必要があります。これは、データがクライアントに送信される前にBEで行われます。したがって、すべてのケースでアクション「許可」が許可されているかどうかのチェックが行われます。

アクションの有効化/無効化は、ユーザーがUIでのみエンティティまたは複数のエンティティを選択したときに行われます。したがって、ユーザーがこの行を選択できるかどうかが明確ではないため、メタデータの追加はおそらく最善の解決策ではないため、チェックが本当に必要になります。

ここでのもう1つの問題は、すでにお伝えしたように、FEはすべての可能なアクションと、FE内のこのアクション名に対するコードを知る必要があることです。

アクションは休息を求めます

ディスカッション中に、別のアイデアも得られます。

ユーザーがUIでエントリを選択した後。ページ上のすべてのアクションは、BEに残りの要求を行うことができます。 （したがって、レンダリングされないすべてのアクションはトラフィックを引き起こしません）

リクエストのコンテンツは、エンティティID（場合によっては＆バージョン）であり、すべてのチェックが行われ（ロジックはBEにのみ存在します）、アクションが許可されているかどうかにかかわらず、BEは情報を返します。

しかし、ここにもいくつかのポイントがあります：

  • BEがIDでエンティティを取得するために再度データベースを要求する必要があるため、遅くなる可能性があります
  • UIでアクションが有効になるまで時間がかかる可能性があります（他のソリューションでは、情報がすでにUIにあるため、アクションをより早く有効/無効にします）

.............................................. .........................

したがって、BEではデータにメタ情報を追加するため、使用できるデフォルト（HATEOAS）があります。

許可されているかどうかを確認するためにBEにリクエストを出すアクションを許可する標準もありますか？

コードを2回コーディングすることも、まだレース中です。

これを行うための「より良い」解決策（ベストプラクティス）を見つけて、新しいアイデアや意見を募集しています。

1
bbqq92