Javascript wysyłanie requestu, ale żeby nie pokazywał się w zakładce sieć

pytanie zadane 27 kwietnia 2022 w JavaScript przez Filipczak Gaduła (4,020 p.)

Cześć, mam zagwostkę, bo chciałbym zrobić tak, aby wpisując w pole np abc, z każdą napisaną dalej literką, wyświetlały się coraz bardziej sprecyzowane wyniki, wiem, że można to zrobić w ajaxie, wysyłając request do np api, jednak chciałbym to rozwiązać w inny sposób, tak żeby załadować javascripta na stronie i żeby nie wyświetlał się dany request w zakładce SIEĆ w dev tools, wiem, że jest coś takiego możliwe jednak nie mam pojęcia w jaki sposób to zrobić, myślałem o websocket, jednak nie wiem czy to jest odpowiednie rozwiązanie pod coś takiego.

komentarz 27 kwietnia 2022 przez rafal.budzis Szeryf (85,260 p.)

Po co ?

komentarz 27 kwietnia 2022 przez Filipczak Gaduła (4,020 p.)

chciałbym nauczyć się czegoś nowego, oraz chciałbym po prostu zapobiec takim sytuacją, że jakikolwiek programista zacznie pobierać dane z mojej strony, albo znacząco to utrudnić

1	komentarz 27 kwietnia 2022 przez Milesq Nałogowiec (32,020 p.) Możesz robić reload co każde kliknięcie XD ale to gorsza praktyka. Użyj fetcha i tyle. Wszystko co wysyłasz z serwera do przeglądarki będzie jawne dla programistów i tak należy te dane traktować

1	komentarz 28 kwietnia 2022 przez PramatycznyJunior Początkujący (420 p.) reload tez bedzie javny, bo requesty zostana zaladowane raz jeszcze.Jesli mowa o reload- samego widoku - wizualnie to i tak na Network pozostanie niezmieniony callstack

komentarz 28 kwietnia 2022 przez Milesq Nałogowiec (32,020 p.)

dokładnie, nie pokaże się w zakładce sieci, ale będzie jawny. Więć tak jak pisałem, wszystko co jest na stronie internetowe, wysyłasz klientowi, czyli programista ma do tego dostęp

1 odpowiedź

odpowiedź 27 kwietnia 2022 przez rafal.budzis Szeryf (85,260 p.)
wybrane 27 kwietnia 2022 przez Filipczak

Najlepsza

Dzięki za wyjaśnienie. Jeśli chodzi o zabezpieczanie się przed kradzieżą danych to są inne sposoby. WebSocket jest do czegoś innego! ;) Jeśli chcesz utrudnić pobieranie danych z twojej strony to:

- dodaj sesje (np. request o HTMLa tworzy sesje, a kolejne requesty nie działają bez sesji. Stworzenie mechanizmu sesji pisząc robota nie jest takie bardzo oczywiste. Szczególnie gdy przy każdym requescie regenerowałbyś ID sesji.)

- zliczaj w sesji ilość requestów w ciągu określonej jednostki czasu. Jeśli ktoś to przekroczy np 10 requestów w ciągu 30 sekund to uznaj że to bot i zablokuj sesje

- próbuj rozpoznać bota po rodzaju requestów. Np jeśli nie było zapytania o HTMLa to blokujesz API.

- jeśli są to dane wrażliwe dodaj na stronie startowej tylko przycisk pokaż dane który bedzie wymagał google reCaptcha

- formularze możesz dodatkowo zabezpieczyć swoim tokenem jednorazowymi.

- rozbij dane na wiele małych requestów aby trudniej było je scalić pisząc bota.

To mi przyszło do głowy pewnie dałoby się jeszcze coś zrobić :) Oczywiście wystarczy zrobić tylko jedne punkt aby było trudniej pobierać twoje dane.

1	komentarz 27 kwietnia 2022 przez rafal.budzis Szeryf (85,260 p.) PS. jeśli dane są dostępne bez logowania lub nie bedziesz blokował kont to tak czy inaczej wystarczy bot napisany w cypress.

komentarz 27 kwietnia 2022 przez edutomek Dyskutant (8,380 p.)

Zwłaszcza to rozbicie danych na wiele małych requestów jest BARDZO irytujące, gdy ktoś chce pobrać dane skryptem. A jeśli do tego dojdą ograniczenia czasowe (np. request co jakiś czas - nie za często, ale i nie za rzadko), to już WNERWICA kompletna się robi. Znam to od tej drugiej strony - pobierającej.

Do tych ciekawych uwag dodałbym jeszcze: zastanowić się, czy te dane, które chcemy chronić, są aż tak istotne, by je zabezpieczać. Zabezpieczenia też kosztują. (Jak ktoś chce się czegoś nauczyć, to nie ma znaczenia.)

Zwrócę również uwagę na prosty fakt: wszystkie te sposoby dotyczą serwera. AFAIK, to nie ma sposobów na (skuteczne) zabezpieczenie informacji po stronie przeglądarki. Jeśli coś wyślemy do klienta, należy założyć, że cokolwiek to było, może zostać pobrane np. przez skrypt. (Ileż to razy zdarzyło mi się usuwać z DOMu różne szybki, czy zasłaniacze, które wyskakiwały na stronach, ukrywające właściwą treść...)

Bardziej irytującym zabezpieczeniem po stronie przeglądarki było zaszyfrowanie treści. Przeglądarka, zapewne po przeskrolowaniu strony na odpowiednią pozycję, wysyłała request do serwera, który zwracał klucz do szyfru. Treść była odszyfrowywana po stronie przeglądarki. Dało się to obejść wywołując "ręcznie" odpowiednie funkcje JS, aczkolwiek nie sprawdzałem, czy np. powinny być one wywoływane po odpowiednim czasie, czy też w odpowiedniej kolejności. Dałem sobie z tym spokój. (Wniosek: było to do złamania, ale w bardzo upierdliwy sposób.)

Jeszcze coś mi się przypomniało: jest pewna strona, z której często pobieram filmy. Każdy film ma unikalne ID. Z jakiegoś powodu, co pewien czas (dwa tygodnie? miesiąc?) zmienia się URL filmu: czasami część adresu, czasami port... W sumie prosta sprawa i łatwa do naprawy w moim skrypcie, ale jednak irytuje. Tyle, że po stronie serwera coś takiego może być też bardziej uciążliwe do zrobienia. (Względnie można założyć, że jest tam kilka serwerów, i każdy działa nieco inaczej, a dostęp do serwerów jest przydzielany z jakieś "karuzeli". Ale to już większy temat - i też wymagałby odpowiedniego zaprogramowania. Dalibóg, nie mam pojęcia, po co robić coś takiego. Żeby zirytować takich "ściągaczy", jak ja?)

A już zupełnie na marginesie, to mamy tu chyba kolejny przykład XY problem: problem w zabezpieczeniu danych przez nieautoryzowanym (powiedzmy) dostępem, a pytanie o wysyłanie requestu, którego ma nie być w logach przeglądarki.

komentarz 27 kwietnia 2022 przez rafal.budzis Szeryf (85,260 p.)

Podmiana adresów / portów brzmi ciekawie :D Ale przyszło mi do głowy najgłupsze a zarazem najlepsze rozwiązanie gdy wspomniałeś o filmie. Odpalać przeglądarke po stronie serwera a do klienta strumieniować wideo :D Żadnych danych nie zobaczy a i z .mp4 będzie trudno coś sczytać :D

Oczywiście zwykły user dużo traci na szybkości,SEO leży, jakość grafiki też. Potrzeba mocnych serwerów aby odpalić X przeglądarek dla X userów. Ale zabezpieczenie było by konkret. :D

Łatwiej by było chyba zrobić po prostu appke na windowsa i zrezygnować z strony.

komentarz 27 kwietnia 2022 przez Filipczak Gaduła (4,020 p.)

@rafal.budzis, Okej, czyli ogólnie to, nie ma sensu co chciałem zrobić? w takim razie czy byłoby to dobrym rozwiązaniem, aby co np 5 requestów tworzyć nowy token który działałby tylko 5 razy?

1	komentarz 27 kwietnia 2022 przez rafal.budzis Szeryf (85,260 p.) Łatwiej by było zrobić po prostu tokeny jednorazowe. Ja bym się nie bawił w zliczanie. PS. tokeny możesz zapisać jako JWT i przechowywać w nich dodatkowe dane jeśli będziesz potrzebować.

komentarz 27 kwietnia 2022 przez Filipczak Gaduła (4,020 p.)

tylko pytanie, czy nie tworzyłoby się za duzo requestów, bo znając życie rozbiłbym je na 2 requesty, chociaż wiem, że mógłbym zrobić to w jednym requeście, oraz pytanie czy to nie zajechałoby serwera i czy takie rozwiązanie byłoby dość szybkie, aby pokazywać od razu po każdym wpisaniu literki rezultat?

komentarz 27 kwietnia 2022 przez Filipczak Gaduła (4,020 p.)

wsm teraz tak myślę, że jakbym zrobił to też w jednym requeście to przecież skrypt kogokolwiek mógłby pobierać dane z jsona żeby pobierać reszte danych

komentarz 27 kwietnia 2022 przez rafal.budzis Szeryf (85,260 p.)

Za szybko się martwisz optymalizacją :) Najpierw zrób, a następnie zobaczysz jak szybko to działa.

Aby nie zajechać serwera po stronie FE w przypadku wyszukiwania daje się debounce aby nie wysyłać requesta co literka, a dopiero jak user przestanie pisać np przez 500 ms.

Działa wolniej ale serwer sobie odpoczywa. Coś za coś. Nie można mieć wszystkiego ;) A dopóki nie napiszesz funkcjonalności trudno będzie Ci znaleźć złoty środek.