W jaki sposób obsługa bezpieczeństwa breeze.js i unikanie ujawniania logiki biznesowej

Rozważamybryza js budować aplikacje korporacyjne.

Niesamowita bryza polega na tym, że możemy wykonywać zapytania bezpośrednio z przeglądarki klienta. Pozwala to na tworzenie dynamicznych zapytań opartych na danych wejściowych użytkowników bez ładowania niepotrzebnych danych. Odkryłem, że używając Breeze możemy stworzyć logikę biznesową, która redukuje ilość danych podróżujących / transferujących o 1/10 lub nawet więcej, gdy używana jest strategia leniwego ładowania. używając zapytań takich jakte

Bryza brawa !!!

Ale co z bezpieczeństwem Logiki Biznesowej? Na przykład moglibyśmy mieć repozytorium, w którym moglibyśmy ukryć, ukryć i zasłonić naszą logikę biznesową; a następnie użyj kontrolerów MVC Web API, aby wywoływać tylko te klasy C # repozytorium. więc Breeze JavaScript rozmawia z kontrolerem WebAPi, a kontroler WebApi rozmawia z repozytorium C #. Kontrolery zawsze będą bardzo proste i łatwe do odczytania, ale repozytorium może mieć wiele logiki biznesowej dla firmy korzystającej z aplikacji. Jeśli więc haker używa na przykład konsoli programisty Google Chrome do sprawdzenia kodu JavaScript, wszystko, co zobaczy, to takie rzeczy, jak GetCustomers (), GetProductsForThisId (54). Nie ma tam zbyt wielu informacji, które można tam zobaczyć (lub skradzić). Ponieważ 90% Logiki Biznesowej będzie żyć w repozytorium C # na serwerze.

Jak radzi sobie z tym breeze.js?

Jeśli zaczniemy przenosić zapytania i logikę biznesową „z kontrolera C # do bryzy JavaScript”, musimy wziąć pod uwagę, że nasz system jest oparty na członkostwie. Myślę, że im więcej zapytań udostępnimy klientowi w JavaScript, tym bardziej narażone jest nasze oprogramowanie, a im więcej hakerzy informujemy, jak włamać się na naszą stronę i ewentualnie wykraść informacje.

questionAnswers(3)

yourAnswerToTheQuestion