Comment breeze.js gère la sécurité et évite d'exposer la logique métier

Question

Nous envisageons de brise js pour construire des applications d'entreprise.

L'awesomeness de brise, c'est que nous pouvons exécuter des requêtes à droite du navigateur du client. Cela permet de constructions dynamique de requêtes basées sur les utilisateurs d'entrée sans chargement de données inutiles. J'ai trouvé que l'utilisation de Brise, nous pouvons créer une logique d'entreprise qui réduit les données de voyage/transfert par 1/10 ou plus encore lors de l'utilisation d'un paresseux stratégie de chargement. à l'aide de requêtes comme ces

Hourra brise!!!

Mais ce que sur la Logique Métier de la sécurité, Par exemple, Nous pourrions avoir un référentiel dans lequel on pouvait dissimuler, cacher et masquer notre logique métier; et ensuite utiliser MVC, Web API contrôleurs de simplement faire des appels à celles du référentiel classes C#. donc, Brise JavaScript parle à la WebAPi contrôleur et le WebApi contrôleur communique avec le C# référentiel. Les Contrôleurs seront toujours très simple et facile à lire, mais le Dépôt peut avoir beaucoup de logique d'entreprise pour la société à l'aide de l'application. Donc, si un pirate utilise par exemple utilise Google chrome développeurs de la console d'inspecter le code JavaScript, tout ce qu'il/elle va voir des choses comme des GetCustomers(), GetProductsForThisId(54). Il n'y a pas beaucoup d'informations qui peut être vu (ou volé) il y a des. Parce que le 90% de la Logique d'Affaires sera en direct sur le C# référentiel sur le serveur .

Comment est breeze.js manipulation ?

Si nous de commencer à faire des requêtes et de la logique métier "De l'contrôleurs de C# à la brise javacript" et en considérant que notre système est inclus dans la cotisation. Je pense que le plus de requêtes que nous exposons au client en JavaScript les plus vulnérables de notre logiciel devient, plus nous dire comment les pirates de pirater notre site et, éventuellement, de voler des informations.

Answer 1

La sécurité est une préoccupation essentielle. Il est sage de réfléchir soigneusement les données et la logique exposée sur le client. Comment pouvons-nous intégrer ces sentiments dans une question concrète adaptée à une SORTE de réponse?

Rien au sujet de Brise doit vous amener à exposer la logique d'entreprise pour le client de JavaScript. Vous pouvez (et devriez) de verrouillage d'une telle logique en toute sécurité à l'intérieur de vos dépôts et/ou de contrôleur de méthodes.

Mais j'ai du mal à comprendre comment le client des requêtes elles-mêmes , sont le genre de logique d'entreprise qui ont besoin de protection. Où est le danger dans une requête pour un client dont le nom commence par 'A'?

Vous pouvez à juste titre s'inquiéter d'une requête pour les clients à valeur nette > de 100 000$. Mais la faute n'est pas dans la requête. La faute serait à exposer des informations sur les clients à des utilisateurs non autorisés par tous les moyens, que ce soit à travers un jeu d'enfant où la clause ajoutée à une requête ou d'un appel à un service nommé GetCustomers().

La place pour bloquer l'accès non autorisé à des clients sur le serveur et vous pouvez le faire aussi facilement à l'intérieur d'une Brise d'action du contrôleur méthode retournant IQueryable que vous pouvez dans votre GetCustomer() méthode. Le fardeau tombe sur vous dans les deux cas, à imposer la sécurité nécessaire les contraintes sur votre contrôleur et dans les méthodes que vous exposez.

Vous écrivez le contrôleur. Vous écrivez les référentiels. Vous avez accès à des autorisations de l'utilisateur. Vous êtes en contrôle complet avec un compromis capacité à exposer autant ou aussi peu que vous le souhaitez.

FWIW, votre Breeze EntityManager pouvez appeler le service méthodes qui ne font pas de retour IQueryable<Customer>. Il peut appeler des Web Api contrôleur de méthodes telles que l' IEnumerable<Customer> GetCustomers() ou Product GetProductForId(int id). À mon avis, vous allez perdre la flexibilité de la Brise, de la requête installations sans avoir aucune sécurité. Mais c'est juste mon avis. Breeze support de votre choix, quel qu'il soit.

Je serais heureux d'essayer de répondre plus précisément le "comment" de la question.

Answer 2

souhaite ajouter que vous pouvez restreindre les utilisateurs qui ne sont pas autorisés à effectuer des requêtes en utilisant les attributs dans webapi si vous récupérez le code 401 du serveur, ouvrez simplement un écran de connexion et refaites le travail nécessaire après la connexion de l'utilisateur

donc un utilisateur peut essayer d'obtenir des données sur une commande mais il ne les obtiendra que s'il y est autorisé