2

コンテキスト: SQL DB に支えられた MVC Web サービス。データベースにユーザー リレーションがあり、一連の FK を介してそれを参照するリレーションのセットがあるとします。たとえば、次のテーブルがあるとします。

sales_people
car_dealership
cars

営業担当者が特定の自動車販売店に所属している場合、自動車もそうです。営業担当者は、特定のディーラーに属する車のみを表示できる必要があります。ここにはいくつかのオプションがあります。

認可ビジネス ロジックを SQL クエリ自体に組み込むことができます。

SELECT *
FROM cars as c, sales_people AS sp, car_dealerships AS cd
WHERE where c.dealership_id = cd.id
AND sp.dealership_id = cd.id
AND sp.id = ?
AND c.id = ?

発信者が sales_people ID が正当であり、その ID の些細ななりすましを防いでいることを確認したと仮定すると、上記のクエリは、ユーザーが自分のものではない車を手に入れるのを防ぎます。結合が大規模すぎない限り、これはおそらく任意の数のテーブルに拡張できます。

アップサイド？1 回の DB 呼び出し。

欠点？

  • ここでの承認ビジネス ロジックは非常に基本的なものです。これらのテーブルのいずれかによって参照されているユーザーですか? もちろん、合格できます。しかし、もっと複雑なアクセス ルールが必要だとしましょう。1 つの単純なクエリでは実行できない可能性があります。
  • ユーザーが許可されていない行を要求したのか、行が許可されているが実際には存在しないのかを判断するのは難しいため、エラー報告が難しくなります。200 と 403 のどちらを報告する必要があるかはわかりません (ただし、API のタイプによっては、これらの場合に常に 200 を使用して、攻撃者に過度の情報が公開されるのを防ぐことができます)。

私が目にする他のオプションは、データが実際にそのユーザーにアクセス可能であることを検証するために、事実の前または後に追加のクエリを作成することです。たとえば、営業担当者が取得を許可されている車の ID のリストを取得し、そのサブセットに対してクエリを実行するか、またはその逆です。

利点は明らかに、ビジネス レイヤーでより多くの呼び出しを行い、より多くのロジックを実行できることです。

欠点は、より多くの DB トラフィックを生成することです。これは、その要求が行われる頻度によっては契約を破る可能性があります。

ここには他にもいくつかのオプションが欠けている可能性があります。以前に問題をどのように解決したかを知りたいです。より良い方法はありますか？

4

2 に答える 2

4

原則として、コードを論理的に動作させてから、他の方法でパフォーマンスをスケーリングする必要があると思います。たとえば、より強力なデータベースを大きくしたり、結果をキャッシュしたりします。

私のアプリケーションでは、複数のクエリを使用しています。システムの時間を測定したところ、5 ～ 10 回の往復で 1 ミリ秒未満かかりました。私にはそれで十分です。私は他の人が複雑なストアド プロシージャを作成して、必要なことをすべて実行するのを見てきました。その結果、データベースから 403 や 404 などを返すことができます。

個人的には、コードをよりクリーンで読みやすくするために、データベースに何度もアクセスすることを好みます。これは、負荷が大きすぎない場合に特に当てはまります。ハードウェアは安価ですが、あなたの時間はそうではありません。

于 2013-07-24T03:12:06.090 に答える
0

これらの問題をさらにいくつかデバッグした後、別の意見を追加したいと思います。

ユーザー (またはアプリケーション コード) に正確に何が間違っているかを伝えるのは良いことです。私の通常のアプローチは、関連するすべてのセキュリティ情報を SQL から返し、アプリケーションでチェックを行うことです。この方法では、データベースへの 1 回の往復で、コードから非常に詳細な情報を得ることができます。たとえば、「この販売店にはアクセスできません。」または「この車は削除されました。」

于 2016-03-17T15:58:57.317 に答える