3

Webサービスを介して通信する2つの別個のシステムがあります。それらをフロントエンドおよびバックエンドと呼びます。多くの処理には、バックエンドのリストの更新が含まれます。たとえば、フロントエンドは特定の人を更新する必要があります。現在、インターフェイスを決定するバックエンドを設計しています。基盤となるデータベースを更新するには、実際のデータベースIDが必要ですが、データベースIDをコンシューマーに伝達することが悪い考えである可能性がある場所もわかります。

特定のエンティティを更新するために、クライアント（つまりフロントエンド）にIDをWebサービスに送り返す必要がある場合の代替策は何ですか？IDを回避しようとしているもう1つの理由は、フロントエンドがこれらの変更を保存して後日送信することが多いためです。これには、フロントエンドがIDをシステムに保存する必要がありますが、これも悪い考えのようです。

私たちは次のことを考慮しました：

1）データベースIDをフロントエンドに送り返します。変更を処理するには、これらを返送する必要があります

2）ハッシュ化されたID（データベースIDに基づく）をフロントエンドに送り返します。変更を処理するには、これらを返送する必要があります。

3）クライアントにIDの送信を強制せずに、元のエンティティと新しいエンティティを送信させ、データベース内のエンティティに「一致」させます。それらの元のエンティティは、保存されたエンティティと一致する必要があります。また、エンティティと新しいエンティティの一致を構成するものを定義する必要があります。

4

2 に答える 2

4

フロントエンドの唯一の合理的な方法は、DB内の人物を何らかの方法で識別することです。

エンティティ全体の照合は信頼性が低く、明らかではありません。ハッシュされたIDをフロントエンドに返すには、最初にフロントエンドからハッシュされていないIDを受け取るか、IDの下で元に戻すことができる「ハッシュ」（「暗号化」など）を実行する必要があります。

私見では、それがデータベースIDであるか、IDを抽出できるデータ（暗号化されたデータベースID）であるかは関係ありません。データベースIDを知っている消費者が悪い考えだと思うのはなぜですか？すべての人が単一の消費者に属している限り、問題はありません。

人（DB内のオブジェクト）とコンシューマーの間に多対多の関係がある場合は、オブジェクトIDを（広義には）「暗号化」して、暗号化がコンシューマーに依存するようにすることができます。たとえば、コンシューマとの通信では、DB内のリンク（オブジェクトとコンシューマの間）エントリのIDを使用できます。

消費者がすべてのIDを1つずつ列挙する可能性があるため、消費者にIDを送信するのが悪いと思われる場合は、整数の自動インクリメントIDの代わりにGUIDを使用することで、この問題を回避できます。

PS：コメントについては、たとえばGUIDをオブジェクトIDとして使用することを検討してください。IDはデータの一部であり、スキーマの一部ではないため、データベース間で移行するときに保持されます。このようなIDには機密情報も含まれないため、消費者（または他の誰か）にIDを公開することは完全に安全です。同じSSNを持つ2人の異なる人物の作成を防ぎたい場合はUNIQUE、SSNフィールドにキーを追加するだけですが、IDの一部としてSSNを使用しないでください。このようなアプローチには多くの重大な欠点があり、IDを明らかにすることができません。それらの中で最も少ない。

于 2012-04-18T12:56:33.863 に答える
2

私の見解では、レコードのIDは機密情報を誰にも伝えません。
結果として、データベースIDをフロントエンド（および一般的に）に送信することに問題はありません。
唯一の懸念はデータベースの整合性の問題に関連するでしょうが、私には何も見えません。
さらに、データベースIDを見つけるために属性についてデータベースにクエリを実行する必要がないため、パフォーマンスからははるかに優れています。

さらに、IDのハッシュを送信する場合、ハッシュからIDを抽出することはできません。
データベースでハッシュと一致するIDを見つける必要がありますが、これは適切なIMOではありません。

それで：

また、データベースIDをコンシューマーに伝達することが悪い考えである可能性がある場所もわかります。

見えません。なぜ悪い考えだと思うのか説明できれば、議論があるかもしれません。

于 2012-04-18T13:04:35.643 に答える