0

私のチームでは、エンティティ データの更新とその最適なアプローチ方法について議論しています。これはセキュリティ フレームワークであるため、いくつかの制約とアイデアを次に示します。

  1. DB のすべてのテーブルには、GUID である PK があります。これは、マルチノード クラスタリング ソリューションに必要です。アイデアは、API を介してエンティティでこれを顧客に公開したくないということです。
    1. 彼らの仕事に必要な情報を提供し、システムに関する情報をハッカーに提供します。
    2. サポートの悪夢は、クライアントが何らかの方法でこの ID にハードコードし、PK のクライアントを変更する必要がある場合に影響を受けることです。

解決策は、一意の Name を持つ Role オブジェクトや Realm などのアイテムの自然キーを公開することです。一意性を保証しますが、これらの値のいずれかを更新することは困難です。更新する古い値と新しい値を指定するか、2 つを渡す必要があるためです。元のオブジェクトと新しいオブジェクトのオブジェクト。更新するオブジェクトを見つけることができます。ややこしい、

別のアプローチは、代替キーを作成し、これをクライアントに公開して、クライアントが必要なだけ使用できるようにすることです。これは、PK に関連付けられていないため、気にしません。

最近では誰もがエンティティの ID として PK を問題なく使用しているように見えますが、昔のプログラミングの時代からベテランのチームを説得する方法がわかりません。

もう 1 つの問題は、部分的な更新をサポートする方法です。問題は、10 個のプロパティ、4 つのコレクションなどを持つエンティティがあり、名前 + レルムのコンボを使用して、オブジェクト全体をプルダウンする代わりに更新するプロパティを指定し、1 フィールドを変更して送り返すことです。アップデート用。コレクションを遅延ロードすると言いますが、部分的な更新が意味があるかどうかはわかりません。

考え？

ありがとう！

4

3 に答える 3

1

セキュリティ フレームワークに対する私のアプローチは次のようになります。

  • データベース内のすべてのものに内部 ID (ID 列、シーケンス、データベースがサポートするものは何でも。Hibernate の「ネイティブ生成 ID 列」) を指定します。最終的にはそれが必要になり、後付けするのは大変な作業です。

  • ユーザーに ID を渡す必要がある場合は、乱数を生成し、それがまだ使用されていないことを確認し、それを内部 ID に関連付けてから、ユーザーに渡します。内部 ID を配布したり、クラッカーが推測できる ID を使用したりしないでください。

部分的な更新に関しては、多くの属性を持つオブジェクトがたくさんある場合にのみ意味を持ち始めます。10 個の属性については、「時期尚早の最適化」と言えます。

于 2009-05-28T07:24:21.950 に答える
0

すべてのテーブルでGUIDを主キーとして使用することは、問題を抱えているように聞こえます。私が本当にあなたを誤解していない限り、私はこのアプローチがどこでも取られているのを見たことがありません。すべてのユーザーにUIDを発行して、そのUIDを操作してみませんか？

このアプローチは、すべての企業で最も一般的です。UIDはPIIではないため、セキュリティの観点からは、法的に問題ありません。

于 2009-05-28T07:52:34.360 に答える
0

IDをクライアントに公開する必要がある場合は、自然キーを使用します。実装はそれほど簡単ではありませんが、それは正しい方法です。

それらの部分的な更新についてもう少し詳しく教えていただけますか？聞き取れませんでした。：/

于 2009-05-28T06:59:22.923 に答える