angularjs - AngularJS + Breeze +安全

2015年3月2日更新

感谢您提出的澄清意见……这反映了广泛关注的问题。 我真的将不得不在我们的文档中对此进行详细介绍。

幸运的是，我相信我可以使您对提出的具体问题放心。

客户端库BreezeJS仅能访问服务器允许当前用户访问的数据。 授予或拒绝此类请求是服务器的工作。

这是从根本上对任何技术交谈，与任何技术编写的服务器写入的客户端同样的故事。 如果服务器具有“客户”端点，则除非您使用服务器上的逻辑来保护该端点 ，否则客户可以请求所有客户并将其接收。 有或没有微风都是如此。

您可能会认为元数据描述了整个数据库架构，因此将整个数据库暴露给Breeze客户端请求。 该说法有两个事实是不正确的。

首先，即使客户端知道您的整个数据库架构，也无法使用该知识执行任何操作，除非您麻烦使用无保护的端点公开Web api中的每个表。 这完全在您的控制范围之内，并非偶然可以执行的操作。

其次，没有充分的理由发送描述整个数据库的元数据。 如果让服务器根据Entity Framework模型生成元数据，则可以轻松地将该模型的大小和形状限制为要在面向客户端的api中公开的数据库子集。

在将模型和Web API缩小到适合您的应用程序的大小和形状之后，您必须采取下一步……对于可以想象的任何Web API采取的步骤……就是要保护端点。

至少这意味着确保对用户进行身份验证和授权以提出每个端点的请求。 但这也意味着即使对授权用户的请求也要防止不必要的响应。 例如，您可能希望限制服务器上可以为任何给定客户查询返回的客户数量。 您可能希望限制在单个时间间隔内要处理的请求数量。 您可能希望将客户筛选为仅允许用户看到的少数几个。

做这些事情的技术都是ASP.NET Web API本身的一部分，与Breeze无关。 您将要研究Web API必须提供的选项。

使用ASP.NET Web API的Breeze组件，实际上更容易进行更新。 传统的Breeze更新机制是批量发布到单个SaveChanges端点。 换句话说，攻击的表面积可以限制为单个端点。 .NET的Breeze SaveChanges方法为安全性和完整性检查提供了两个拦截点：

BeforeSaveEntity ，您可以在其中将每个实体保存到数据库之前分别进行检查和确认。

BeforeSaveEntities在那里你可以检查整个批次作为一个整体 ......以确保保存请求是凝聚力和合法的。 在简单的REST-ish api中，您无法做到这一点，在该API中，PUT / POST / DELETE请求作为单独的自主事件到达

Breeze查询语言具有很高的表达能力，因此客户端可能会向服务器查询您不期望的内容。 在这方面， expand子句可能是最“危险的”。 有人可以查询“客户”端点并同时获取其相关的订单，相关的OrderDetails，相关的产品等。

那是一个强大的力量，随之而来的是责任。 您可以选择拒绝expand查询来保留此功能。 您可以拒绝select可以通过选择相关实体来“扩展”的查询。 ASP.NET Web API使施加这些限制变得容易。

或者，您可以在某些情况下允许expand在其他情况下则不允许。 或者，您可以在GET端点的实现中检查查询请求，如果安全检查未通过，则拒绝该请求。

您可以决定根本不希望某些实体类型是“可查询的”。 您可以只创建支持安全访问那些高度敏感类型所需的专用GET端点。 如果支持方法不返回IQueryable ，则Breeze或Web API都不会尝试将OData查询参数转换为LINQ查询。 这些端点的外观和行为完全类似于您现在熟悉的传统REST式api。 Breeze的客户将很高兴与您一起游戏。 当您编写Breeze查询时，客户端不知道服务器是否会接受该请求。 使用Breeze，您可以编写所需的任何请求，并将其发送到所需的任何HTTP端点。 您不仅限于OData样式的查询。

您不需要一种查询方法。 您可以决定公开哪些实体类型，如何公开以及在什么条件下公开。 您可以并且应该编写保护逻辑，以确保查询返回正确的数据或通过保存更新正确的数据，就像使用任何 Web api一样。 Breeze和Web API都为您提供了丰富的工具来编写这种保护逻辑。 您的选择不受限制。

最后，我观察到，面向Breeze的api往往比典型的RESTy api小得多……也就是说，它们提供的端点更少，并且（从这个意义上来说）表面积更小。 实际上，这意味着您可以将服务器端安全性预算集中在更少的方法上，并有可能提高代码的质量和检查api的安全性风险的能力。