Czy nie jest niebezpieczne posiadanie informacji o zapytaniach w javascript za pomocą breezejs?

Question

Po prostu zaczyna się grać z breeze.js ze względu na oczywiste korzyści w czasie kodowania, tj. Zarządzanie dostępem do danych modelu z serwera bezpośrednio w JavaScript (jestem tutaj początkującym, tak oczywistym!).

W przeszłości korzystałem z wywołań ajaxowych w celu uzyskania/wysłania danych na serwer, a w przeszłości korzystałem z kilku różnych narzędzi klienckich, aby zapewnić pomoc w wyszukiwaniu lokalnych danych, takich jak jLinq.

Moje pytanie jest takie. Czy w języku JavaScript nie jest niebezpieczne posiadanie w zasadzie pełnego dostępu do kwerendy modelu? Muszę czegoś przegapić, ponieważ wygląda na naprawdę dobrze przemyślane narzędzie. W przeszłości przynajmniej kontrolowałem, co można wysłać do klienta za pośrednictwem procesu zapytania backendu, i znowu używając czegoś takiego jak jLinq itd. Mogłem filtrować dane itp. Mogę też zrozumieć kompromis, być może z uzyskaniem bezpośredniego zapytania/brak powielania problemu z lokalnym modelem, więc czy ktoś mógłby w tym pomóc?

Dzięki!

EDIT Oczywiście nie jestem jedyną osobą, jednak jestem zgadywania istnieje uzasadnione odpowiedzi - być może ograniczając dane są wymagane przy zastosowaniu metod Dto czy coś? The other question posted is here

Answer 1

Przedstawienie pełnego modelu biznesowego może być niebezpieczne. Niebezpieczne może być zezwolenie na nieograniczoną kwerendę nawet tej części modelu, która ma zostać udostępniona klientowi. Jest to prawdą, niezależnie od tego, czy oferujesz łatwy w zapytaniu interfejs API, czy taki, który jest trudny do wyszukania.

Dlatego nasze zespoły zwracają uwagę na to, jak budujemy nasze usługi.

Należy ujawniać typy, których potrzebuje aplikacja kliencka. Jeśli chcesz ograniczyć dostęp do autoryzowanych instancji danego typu, możesz napisać dokładnie zalecane metody serwisowania, których nie można przypisać. Breeze może je nazwać dobrze. Nie musisz korzystać z funkcji zapytań Breeze dla każdego żądania.Nadal będziesz korzystać z buforowania, nawigacji związanej z jednostkami, śledzenia zmian, sprawdzania poprawności, składowania w pakietach, wysyłania zapytań do pamięci podręcznej, obsługi offline.

Powtórz: Twoje metody serwisowe nie muszą zwracać IQueryable. Nawet gdy zwracają IQueryable, możesz łatwo napisać metodę usługi, aby ograniczyć wyniki kwerend do tylko tych elementów, które użytkownik ma uprawnienia do wyświetlania.

Na szczęście można połączyć oba podejścia w tej samej usłudze lub w usługach współpracujących.

Breeze daje ci wybór. Od Ciebie zależy, czy mądrze wybierzesz te opcje. Wyjdź tam i zaprojektuj swoje usługi, aby spełnić Twoje wymagania.

Answer 2

Bryza nie jest przeznaczona do być Twojej logiki biznesowej w tym sensie. Mając na uwadze regułę, że jeśli robisz coś w JavaScript, każdy może to zrobić, powinieneś ograniczać widoczność własnych danych usługi w razie potrzeby.

Innymi słowy, przydaje się to, jeśli chcesz, aby dane były publicznie widoczne. Ale ujawniaj tylko te podmioty, które są szczęśliwe, ujawniając i pozwalając każdemu na zapytanie; innym sposobem patrzenia na to jest to, że twój interfejs API staje się publicznym interfejsem API dla twojej witryny (ale nie takim, który reklamujesz i mówisz wszystkim, aby go użył).

Jestem osobiście nie jestem fanem robienia rzeczy w ten sposób, ponieważ istnieje zależność utworzona na schemacie realizacji backendu. Jeśli chcę wprowadzić zmiany w tabelach baz danych, muszę wziąć pod uwagę moją JavaScript. Brakuje mi także integracji i testów jednostkowych.

Jednak może mieć swoje zastosowania, jeśli chcesz szybko zbudować funkcję strony internetowej na niewrażliwych danych bez konieczności budowania metod obsługi i różnych warstw jej wdrażania.

Answer 3

Co zrobić, gdy eksponujesz metadane? Czy nie jest to uważane za niebezpieczne. IMHO nie może bezpiecznie ujawniać metadanych z DbContext. Wiem, że możesz konstruować metadane na kliencie, ale chodzi o to, aby robić rzeczy tak szybko, jak to możliwe (jeśli jest to bezpieczne).