11

我一直在尝试考虑如何使用实体框架实现行级安全性。这个想法是有一个数据库不可知的手段，它将提供方法来限制来自 ObjectContext 的行。

我最初的一些想法涉及修改由 EDMGEN 工具创建的部分类，这提供了一些有限的支持。用户仍然可以通过使用他们自己的 eSQL 语句和 QueryObject 来绕过这个解决方案。

我一直在寻找一个存在于数据库提供者之上的综合解决方案，以便它保持不可知论。

4

5 回答 5

11

当然你可以做到。要做的重要事情是阻止对对象上下文的直接访问（防止用户构建自己的 ObjectQuery），而是为客户端提供一个更窄的网关来访问和改变实体。我们使用Entity Repository 模式来做到这一点。你可以找到一个

但是，有一些微妙之处需要考虑。如果您通过存储库模式在某个实体类型上实现行级视图安全性，那么您必须考虑客户端可以访问相同实体的其他方式。例如，通过导航关系。您可能需要将其中一些关系设为私有，您可以在模型中执行此操作。您还可以选择为加载/保存实体指定自定义查询或存储过程。存储过程往往是特定于数据库服务器的，但可以以通用方式编写 SQL。

虽然我不同意实体框架无法做到这一点，但我同意“在数据库服务器上执行”评论，因为您应该实施深度防御。

于 2008-10-08T13:24:21.790 回答
2

您添加安全性的地方实际上取决于您要保护的对象。

例如，如果您要保护网站，那么在上下文级别添加过滤就足够了，因为在这种情况下，“用户”在网站上。他们别无选择，只能通过您的上下文，因为您将完全根据上下文编写应用程序。

就您而言，听起来您要保护的“用户”是开发人员。这要困难得多。如果开发人员无权对数据库本身进行修改，那么您必须将安全性置于数据库级别。再多的 eSQL 访问都无法绕过数据库说“不”。

于 2008-10-04T18:30:21.720 回答
1

根据定义，您要实现的目标是不可能的。

如果底层数据库应用程序（SQL Server、Oracle 等）没有显式处理安全性，那么 SQL Management Studio 等标准工具将直接超越它。

您可以做的最好的事情是仅当应用程序的用户无法通过其他机制访问数据库时才强制执行行级安全性。

于 2008-10-07T01:49:25.983 回答
1

您可能会发现这篇文章很有用：

http://msdn.microsoft.com/en-us/magazine/ff898427.aspx

“拒绝表访问实体框架而不引起叛变”

于 2012-03-15T12:22:51.377 回答
0

我找到了一种使用 Postgres 和名为Veil的扩展的方法。它实际上适用于（设计用于）Views用于所有操作（选择、更新、删除、插入）并验证WHERE子句中的权限。但是，Veil 只是添加了有效管理内存中权限信息的数学运算，而不是每次都查询它。因此，使用 Veil，尽管您直接连接到 DBMS，但您只获得了行级访问权限。

我在某些方面用面纱修改了我的风格，例如，我开始使用Triggers而不是Views应用权限限制。

我建议您研究此解决方案并尝试在此处应用其逻辑。

即：您进行select * from table查询并得到您想要的内容（行级发言）。

于 2016-02-12T14:45:53.743 回答