我们正在考虑使用breeze js来构建企业应用程序.
微风的真棒是我们可以直接从客户端浏览器执行查询.这允许基于用户输入构造动态查询而不加载不必要的数据.我发现使用Breeze我们可以创建业务逻辑,当使用延迟加载策略时,可以将数据传输/传输减少1/10甚至更多.使用查询,如这些
万岁微风!
但是,商业逻辑安全性如何呢?例如,我们可以拥有一个存储库,我们可以在其中隐藏,隐藏和模糊我们的业务逻辑; 然后使用MVC Web API控制器来调用这些存储库C#类.所以Breeze JavaScript与WebAPi控制器进行通信,WebApi控制器与C#存储库进行通信.控制器将始终保持非常简单和易于阅读,但存储库最终可能会使用该应用程序为公司提供大量业务逻辑.因此,如果黑客使用谷歌Chrome开发人员的控制台来检查JavaScript代码,那么他/她将看到的就像GetCustomers(),GetProductsForThisId(54).那里没有太多可以看到(或被盗)的信息.因为90%的Business Logic将存在于服务器上的C#存储库中.
breeze.js如何处理?
如果我们开始将查询和业务逻辑"从控制器的C#移动到微风JavaScript",我们必须考虑到我们的系统是基于成员资格的.我认为我们在JavaScript中向客户端公开的查询越多,我们的软件就越容易受到攻击,我们就越会告诉黑客如何破解我们的网站并可能窃取信息.
War*_*ard 44
安全是至关重要的问题.仔细考虑客户端上暴露的数据和逻辑是明智的.我们如何将这些情绪细化为适合SO答案的具体问题?
关于Breeze的任何内容都不应该让您将业务逻辑暴露给JavaScript客户端.您可以(并且应该)在存储库和/或控制器方法中安全地锁定此类逻辑.
但我很难理解客户端查询本身是如何需要保护的业务逻辑.查询名称以"A"开头的客户的危险在哪里?
您可能正确地担心对净值> 100,000美元的客户进行查询.但是错误不在查询中.错误在于通过任何方式将此类客户信息暴露给未经授权的用户,无论是通过附加到查询的Breeze where子句还是通过调用名为GetCustomers()的服务.
阻止未经授权访问客户的地方在服务器上,您可以在Breeze控制器操作方法中轻松地执行此操作,返回IQueryable,就像在GetCustomer()方法中一样.在任何一种情况下,您都要承担必要的安全约束,并在您公开的方法中施加必要的安全约束.
你写控制器.你写了存储库.您可以访问用户的权限.您可以完全掌控并具有无可挑剔的能力,可以根据自己的喜好进行曝光.
FWIW,您的Breeze EntityManager可以调用不返回的服务方法IQueryable<Customer>.它可以调用Web Api控制器方法,如IEnumerable<Customer> GetCustomers()或Product GetProductForId(int id).在我看来,如果不获得任何安全性,您将失去Breeze查询工具的灵活性.但那只是我的个人意见.微风将支持您的选择,无论它是什么.
我很乐意尝试回答更具体的"如何"问题.
| 归档时间: |
|
| 查看次数: |
8479 次 |
| 最近记录: |