How is breeze.js handling security and avoiding ex

问题:

We are considering breeze js to build enterprise applications.

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

Hooray breeze!!!

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 .

How is breeze.js handling that ?

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.

回答1:

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?

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.

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'?

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().

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, 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.

回答2:

would like to add that you can restrict users that are not authorized from quering by using the attributes in webapi if you get 401 code back from the server just popup a login screen and redo the work needed after the user is logged in

so a user may try to get data about an order but he won't get it unless he is authorized to do so

回答3:

You can to a lot of stuff using breeze.js First of all check my answer regarding security here

How to handle authorization with Breeze JS?

Also although breeze.js can be used like a normal ORM on the client (which can be extremely helpful at times), you should keep your business logic in web api controllers and expose only the necessary stuff using OData queries. If you need any data manipulation logic, then you should do it on the server using a specific method for that.

Only UI logic should be present on the client, also consider that there are several performance implications if you start performing multiple queries directly from the client. Either expand the entity graph to load more results or use more specialized methods that return object. Breeze will introspect the results and consume the entities happily without implications.