breeze.js如何处理安全性并避免暴露业务逻辑 [英] How is breeze.js handling security and avoiding exposing business logic

问题描述

我们正在考虑 Breeze js 来构建企业应用程序。

We are considering breeze js to build enterprise applications.

轻而易举的是，我们可以直接从客户端浏览器执行查询。这允许基于用户输入构造动态查询，而无需加载不必要的数据。我发现使用Breeze可以创建业务逻辑，从而在使用延迟加载策略时将数据传输/传输减少1/10甚至更​​多。使用诸如这些

The awesomeness of breeze is that we can execute queries right from the client browser. This allows to constructs dynamic queries based on the users input without loading unnecessary data. I have found that using Breeze we can create business logic that reduces data traveling/transferring by 1/10 or even more when using a lazy loading strategy. using queries like these

祝您万事如意！

但是，关于业务逻辑安全性，
例如，我们可以拥有一个可以隐藏，隐藏和遮掩业务的存储库逻辑;然后使用MVC Web API控制器仅调用那些存储库C＃类。因此，Breeze JavaScript与WebAPi控制器通信，而WebApi控制器与C＃存储库通信。控制器将始终保持非常简单且易于阅读，但是存储库最终可能会为使用该应用程序的公司提供许多业务逻辑。因此，例如，如果黑客使用Google Chrome开发人员的控制台来检查JavaScript代码，那么他/她将看到的只是诸如GetCustomers（），GetProductsForThisId（54）之类的东西。那里看不到（或被盗）的信息太多。因为90％的业务逻辑将驻留在服务器上的C＃存储库中。

But what about Business Logic security, For example, We could have a repository in which we could conceal, hide and obscure our business logic; and then use MVC Web API controllers to just make calls to those repository C# classes. so Breeze JavaScript talks to the WebAPi controller and the WebApi controller talks to the C# repository. The Controllers will always be kept very simple and easy to read, but the Repository may end up having lots of business logic for the company using the application. So if a hacker uses, for example, the Google Chrome developer's console to inspect the JavaScript code, all he/she will see are things like GetCustomers(), GetProductsForThisId(54). There is not much information that can be seen (or stolen) there. Because 90% of the Business Logic will live on the C# repository on the server .

breeze.js如何处理呢？

How is breeze.js handling that ?

如果我们开始将查询和业务逻辑从控制器的C＃转移到微风的JavaScript，则必须考虑我们的系统是基于成员资格的。我认为我们用JavaScript暴露给客户端的查询越多，我们的软件就越容易受到攻击，并且我们告诉黑客的方法越多，它们如何入侵我们的网站并可能窃取信息。

If we start moving the queries and business logic "from the controller's C# to the breeze JavaScript", we have to consider that our system is membership based. I think the more queries we expose to the client in JavaScript, the more vulnerable our software becomes, and the more we tell hackers how to hack our website and possibly steal information.

推荐答案

安全是至关重要的问题。仔细考虑客户端公开的数据和逻辑是明智的。

Security is a vital concern. It is wise to think carefully about the data and logic exposed on the client. How can we refine these sentiments into a concrete question suitable for an SO answer?

关于Breeze的任何事情都不应使您向JavaScript客户端公开业务逻辑。您可以（并且应该）将这种逻辑安全地锁定在存储库和/或控制器方法中。

Nothing about Breeze should cause you to expose business logic to the JavaScript client. You can (and should) lock such logic safely inside your repositories and/or controller methods.

但是我很难理解客户端 如何查询自己 是需要保护的业务逻辑。查询名称以 A开头的客户的危险在哪里？

But I struggle to understand how client queries themselves are the kinds of business logic that need protecting. Where's the danger in a query for a customer whose name begins with 'A'?

您可能会担心查询资产净值大于$ 100,000的客户。但是故障不在查询中。错误可能在于，无论通过附加到查询的Breeze where 子句还是对名为的服务的调用，以任何方式将此类客户信息暴露给未经授权的用户 。 GetCustomers（）。

You may rightly worry about a query for customers with net worth > $100,000. But the fault is not in the query. The fault would be in exposing such customer information to unauthorized users by any means, whether through a Breeze where clause appended to a query or a call to a service named GetCustomers().

阻止未经授权访问客户的位置在服务器上，您可以在Breeze控制器操作方法中轻松地做到这一点，返回 IQueryable ，就像您在 GetCustomer（）方法中一样。在这两种情况下，您都将负担加到您的控制器以及所公开的方法内的必要安全约束。

The place to block unauthorized access to customers is on the server and you can do that as easily inside a Breeze controller action method returning IQueryable as you can in your GetCustomer() method. The burden falls on you in either case to impose the necessary security constraints on your controller and within the methods that you expose.

您编写控制器。您编写存储库。您有权访问用户的权限。您完全掌控，可以毫不妥协地曝光任意数量的东西。

You write the controller. You write the repositories. You have access to the user's permissions. You are in complete control with an uncompromised ability to expose as much or as little as you wish.

FWIW，您的Breeze EntityManager 可以调用不返回<$的服务方法c $ c> IQueryable< Customer> 。它可以调用Web Api控制器方法，例如 IEnumerable< Customer>。 GetCustomers（） 或 Product GetProductForId（int id） 。我认为您将失去Breeze查询工具的灵活性，而不会获得任何安全性。但那只是我的个人意见。微风将支持您的选择，无论如何。

FWIW, your Breeze EntityManager can call service methods that do not return IQueryable<Customer>. It can call Web Api controller methods such as IEnumerable<Customer> GetCustomers() or Product GetProductForId(int id). In my opinion you will lose the flexibility of Breeze's query facilities without gaining any security. But that's just my opinion. Breeze will support your choice, whatever it may be.

我很乐意尝试回答一个更具体的如何问题。

I'd be happy to try to answer a more specific "how to" question.

这篇关于breeze.js如何处理安全性并避免暴露业务逻辑的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！