Row-LevelSecuritywithEntityFramework一直在思考如何用EntityFramework实现行级安全。这个想法是拥有一个数据库不可知的方法，该方法将提供限制来自ObjectContext的行的方法。我最初的一些想法涉及修改由EDMGEN工具创建的部分类，但支持有限。用户仍然可以使用自己的eSQL语句和QueryObject来解决这个问题。我一直在寻找一个全面的解决方案，该解决方案将存在于数据库提供者之上，因此它仍然是不可知的。当然可以。重要的是要防止直接访问对象上下文（防止用户构建自己的ObjectQuery），而是为客户端提供一个更窄的网关来访问和改变实体。我们使用实体存储库模式进行操作。您可以在这篇博文中找到针对实体框架的此模式的示例实现。同样，关键是要防止访问对象上下文。请注意，对象上下文类是部分的。所以你应该能够防止它的“未经授权”实例化，即在你的存储库程序集之外。但是，有一些微妙之处需要考虑。如果您通过存储库模式为实体类型实现行级视图安全性，则必须考虑客户端可以访问同一实体的其他方式。例如，通过导航关系。您可能需要将某些关系设为私有，这可以在您的模型中进行。您还可以选择指定用于加载/保存实体的自定义查询或存储过程。存储过程往往是特定于数据库服务器的，但是SQL可以用通用的方式编写。虽然我不同意实体框架不能这样做，但我同意“在数据库服务器上做”的评论，因为你应该实施深度防御。在何处添加安全性实际上取决于您要保护的对象。例如，如果您正在保护一个网站，那么在上下文级别添加过滤就足够了，因为在这种情况下，“用户”在网站上。他们别无选择，只能传递您的上下文，因为您将完全根据上下文编写您的应用程序。就您而言，听起来您要防范的“用户”是开发人员。这有点困难。如果开发人员没有修改数据库本身的权限，那么您必须将安全性放在数据库级别。没有多少eSQL访问能够绕过数据库并说“不”。从定义上讲，您要实现的目标是不可能的。如果底层数据库应用程序（SQLServer、Oracle等）未明确处理安全性，SQLManagementStudio等标准工具会覆盖它。您可以做的最好的事情是仅当应用程序用户无法通过其他机制访问数据库时，才对这些用户实施行级安全性。您可能会发现这篇文章很有用：http://msdn.microsoft.com/en-us/magazine/ff898427.aspx“拒绝访问实体框架而不引起叛乱”我找到了一种使用Postgres的方法和一种名为Veil扩展的方法。它实际上将视图用于所有操作（选择、更新、删除、插入）并验证WHERE子句中的权限。但是Veil只是为了高效地管理内存中的权限信息而不是每次都去查询，只是增加了数学运算。因此，使用Veil，虽然您直接连接到DBMS，但您只能获得授予您的行级访问权限。我在某些方面用veil修改了我的风格，例如，我开始使用Triggers而不是Views来应用权限限制。我建议您研究此解决方案并尝试在此处应用其逻辑。即：你在select*fromtable中select*fromtablequery，就可以得到你的intent（rowlevel）。以上就是C#学习教程：行级安全与实体框架的全部内容。如果对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。涉及侵权，请点击维权联系管理员删除。如需转载请注明出处：
