实体框架中的用户/组织上下文限制
本文关键字：上下文 框架 用户 实体 | 更新日期: 2023-09-27 17:55:31
我正在开发一种网络服务，该服务将为具有相同数据结构的不同组织提供服务。我正在寻找更安全的方法来保持许多组织的数据分离并避免不安全的直接对象引用。
我可以通过以下方式实现它：
-
为每个数据库查询传递用户 ID 信息（获取此用户的组织，检查请求的资源是否与某个组织相关，等等）。
-
为每个组织创建单独的数据库实例，并在会话初始化期间提供特定组织的连接字符串。
第一种方法看起来有点无聊，需要对每个请求格外注意。很容易错过验证，某些用户将能够通过在自己的请求中传递随机 ID 来探索来自其他组织的数据。
第二种方法消除了所有关于额外过滤的头痛。但是我将使用云数据库，每个新实例都需要额外的付款，所以我想避免这种情况。
是否可以以其他方式维护实体框架上下文？
关于这个问题不能明确回答。您需要考虑许多因素，例如未来的数据量，数据隐私级别，组织代表是否需要访问数据库，牢记设计错误的风险等。组织的数量也值得考虑。如果组织数量较少，例如多达 3-5 个组织，有时将数据放在单独的数据库中是有意义的。Azure允许你毫无问题地做到这一点，至少你不需要为数据库的数量付费。如果有许多组织并且您的应用程序将具有SaaS类型，我会认为将数据放在单个数据库中。这样的实现不是很复杂。