实体更新策略
我的团队对更新实体数据以及如何最好地处理它进行了一些讨论。 这是一个安全框架，因此这里有一些限制和想法。
- DB 中的每个表都有一个 PK，它是一个 guid，这是我们的多节点集群解决方案所必需的。 我们的想法是，我们不想通过 API 将实体上的信息公开给客户，因为它可以做两件事，
- 为他们提供工作所需的更多信息，并为黑客提供有关系统的更多信息。
- 支持噩梦是客户端以某种方式硬编码到此 ID，如果我们需要更改 PK，客户端就会受到影响。
解决方案是公开项目的自然键，例如具有唯一名称的角色对象和领域，共同保证唯一性，但是更新这些值中的任何一个都是挑战，因为您需要指定要更新的旧值和新值，或者传递两个值原始对象和新对象中都有对象，因此我们可以找到要更新的对象。 有点混乱，
另一种方法是制作一个备用密钥并将其暴露给客户端，他们可以随心所欲地使用它，而我们不在乎，因为它与我们的 PK 无关。
似乎现在每个人都只是使用 PK 作为实体的 ID，没有任何问题，不知道如何说服我们过去编程时代的退伍军人团队。
另一个问题是如何支持部分更新，问题是您拥有具有 10 个属性、4 个集合等的实体，具有名称+领域组合，并指定要更新的属性，而不是下拉整个对象更改 1 字段，发回用于更新。 我说延迟加载集合，但不确定部分更新是否有意义。
想法？
谢谢！
There is some discussion on my team about updating entity data and how best to approach it. This is a security framework and so here are some of the constraints and ideas.
- every table in DB has a PK that is a guid, this is required for our multi-node clustering solution. The idea is that we don't want to expose this on an entity to a customer via an API because it could do two things,
- give them more info that needed for their job and giving hackers more information about the system.
- support nightmare is that a client hardcodes to this ID in some fashion and if we need to change our PK's clients are impacted.
solutions are to expose the natual key of the items like Role object with a unique Name, and Realm, together guarentee uniqueness however updating either of these values is the challenge, cause you need to specify the old and new values to update, or pass two objects in original and new object, so we can find the one to update. kind of messy,
another approach is to make an alternate key and have this exposed to the client they can use it all they want and we don't care cause it isn't tied to our PK.
it seems everyone these days just uses PK as ID for entities with no issues, not sure how to convince our team of veterns from the old timey programming days.
Another issue is how to support partial updates, issue is that you have entity with 10 properties, 4 collections, etc... with a name+realm combo and specify what property to update instead of pulling down whole object change 1 field, send back for update. I say lazy load the collections, but not sure if partial update makes sense.
thoughts?
thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我的安全框架方法如下：
为数据库中的任何内容提供一个内部 ID（身份列、序列，无论您的数据库支持什么。Hibernate 中的“本机生成的 id 列”）。 最终，您将需要它，并且改造需要大量工作。
为
如果您需要将 ID 交给用户，请生成一个随机数，检查它是否尚未使用，将其连接到内部 ID，然后将其交给用户。 决不泄露内部 ID，并且决不使用可以被黑客猜到的 ID。
至于部分更新，只有当您有大量具有大量属性的对象时，它们才开始有意义。 对于 10 个属性，我会说“过早优化”。
My approach for a security framework would be like this:
Give anything in the database an internal ID (identity column, sequence, whatever your database support. "native generated id column" in Hibernate speak). Eventually, you're going to need it and to retro-fit is a lot of work.
If you need to hand an ID to the user, generate a random number, check that it hasn't been used already, connect it to an internal ID and then hand it to the user. Never hand out the internal ID and never use IDs that can be guessed by crackers.
As for partial updates, they only start to make sense if you have lots of objects with lots of attributes. For 10 attributes, I would say "premature optimization."
如果需要向客户端公开 id，请使用自然密钥。 虽然实施起来并不容易，但这是正确的方法。
您能否提供有关这些部分更新的更多详细信息？ 我没明白。 :/
Use natural key if you need to expose id to client. It's not so easy to implement, but that's the correct way.
Could you provide little bit more details about those partial updates? I didn't get it. :/
在每个表上使用 GUID 作为主键听起来像是自找麻烦。 我还没有在任何地方看到过这种方法，除非我真的误解了你。 为什么不直接向每个用户颁发一个 UID 并使用该 UID 呢？
这种方法在所有公司中最为常见。 UID 不是 PII，因此从安全角度来看，您在法律上是没问题的。
Using GUIDs on every table as a primary key sounds like asking for trouble. I have not seen this approach taken anywhere unless I am really misunderstanding you. Why not just issue a UID to every user and work with the UID?
This approach is most common across all companies. The UID is not PII so you are okay legally as was as from a security point of view.