• Najnowsze pytania
  • Bez odpowiedzi
  • Zadaj pytanie
  • Kategorie
  • Tagi
  • Zdobyte punkty
  • Ekipa ninja
  • IRC
  • FAQ
  • Regulamin
  • Książki warte uwagi

Walidacja danych przez serwer API

Aruba Cloud - Virtual Private Server VPS
0 głosów
427 wizyt
pytanie zadane 29 września 2020 w Inne języki przez poldeeek Mądrala (5,980 p.)
Zastanawia mnie czy pisząc serwer powinno się rozstrzygać każdy przypadek otrzymanych danych, nawet praktycznie niemożliwych. Co mam na myśli. Np czy jeśli dostajemy request o like dla posta, to czy powinno się najpierw sprawdzić czy ten użytkownik już polajkował taki post ? Albo wysyłając zaproszenie do znajomych sprawdzić, czy takie zaproszenie od takiego i takiego użytkownika do takiego i takiego użytkownika już istnieje ?

Pytam, ponieważ i tak weryfikuje te dane po stronie front-end'u i nie wiem czy po stronie backend'u mimo wszystko powinno się roważać takie sytuacje, nawet jeśli front-end w teorii nie pozowoli na requesty np o polajkowanie już polajkowanego postu ?

2 odpowiedzi

+2 głosów
odpowiedź 29 września 2020 przez ScriptyChris Mędrzec (190,190 p.)
wybrane 29 września 2020 przez poldeeek
 
Najlepsza

Pytam, ponieważ i tak weryfikuje te dane po stronie front-end'u i nie wiem czy po stronie backend'u mimo wszystko powinno się roważać takie sytuacje, nawet jeśli front-end w teorii nie pozowoli na requesty np o polajkowanie już polajkowanego postu ?

Walidacja frontendu jest w głównej mierze po to, aby w czytelny i szybki sposób dać użytkownikowi informacje, że nie może wprowadzić danych w określonym formacie lub jakie dane są akceptowane i obowiązkowe. Weź pod uwagę, że z serwerem/API można komunikować się poza przeglądarką (albo z jej konsoli), co w zasadzie umożliwia ominięcie mechanizmów walidacji apki frontendowej. Walidacja backendu powinna być obowiązkowa (i spójna, a nawet bardziej rozległa niż frontu), bo kod w apce na froncie dociekliwy użytkownik może ominąć/zmienić/"uszkodzić".

komentarz 29 września 2020 przez poldeeek Mądrala (5,980 p.)
Czyli rozumiem, że należy sprawdzać wszystko do tego stopnia, że przy takim zapraszaniu do znajomych sprawdzać mimo wszystko, czy istnieje użytkownik zapraszający, czy istnieje użytkownik zapraszany, czy istnieje już zaproszenie najpierw z jednej strony, potem z drugiej strony itd... ? Pisząc w nodzie i mongodb, wszystkie takie zapytania są na zasadzie promise'ów i szczerze mówiąc robi się straszny kocioł kiedy w 6 takich zapytaniach w .then() mamy kolejne zapytanie, a jedyne co mi przychodzi do głowy to async i await, aby to jakoś czytelnie w miare wyglądało....
1
komentarz 29 września 2020 przez ScriptyChris Mędrzec (190,190 p.)

Czyli rozumiem, że należy sprawdzać wszystko do tego stopnia, że przy takim zapraszaniu do znajomych sprawdzać mimo wszystko, czy istnieje użytkownik zapraszający, czy istnieje użytkownik zapraszany, czy istnieje już zaproszenie najpierw z jednej strony, potem z drugiej strony itd... ?

Załóżmy, że masz przycisk na froncie, który lajkuje post. Klikasz i ślesz request, żeby backend zinkrementował licznik polubień posta X. Frontu nie obchodzi, czy taki post istnieje, czy nie - on wie, że backend wystawił endpoint do lajkowania i oczekuje np. identyfikator posta (plus token autoryzujący użytkownika, który lajkuje). Front wysyła taki request, a backend musi sprawdzić, czy jest możliwa ta operacja, bo jeśli tego nie sprawdzisz, to operacja może się wysypać np. na próbie inkrementacji licznika polubień na nieistniejącym (albo ukrytym, albo zablokowanym) poście. Jeśli są z tym jakieś problemy, to backend może zwrócić odpowiedź do frontu z jakimś kodem, front to interpretuje i pokazuje użytkownikowi "Sorry, ale nie udało się polajkować posta...". Taki request - jak wspomniałem w odpowiedzi - można wysłać z konsoli przeglądarki, z innej strony (jeśli serwer obsługuje CORS) lub z jakiegoś curl-a - więc nawet jeśli byś zrobił taką rozbudowaną walidację na froncie, to można to z łatwością ominąć. Backend musi więc tego typu akcje walidować.

Pisząc w nodzie i mongodb, wszystkie takie zapytania są na zasadzie promise'ów i szczerze mówiąc robi się straszny kocioł kiedy w 6 takich zapytaniach w .then() mamy kolejne zapytanie, a jedyne co mi przychodzi do głowy to async i await, aby to jakoś czytelnie w miare wyglądało....

Jeśli tworzysz API w Node, to warto korzystać z frameworka, typu Express, który oferuje metody z wygodną obsługą middleware'ów - więc powtarzalne walidacje możesz porozdzielać po funkcjach i przekazywać je w odpowiedniej kolejności do endpointów.

Składnia async/await to cukier składniowy pozwalający na pominięcie używania then, przez co kod wygląda na synchroniczny, ale to nie za bardzo ma wpływ na architekturę aplikacji - nadal działa się na promisach. Tę powinieneś podzielić względem odpowiedzialności na np. moduły, które będą zajmować się konkretną rzeczą: obsługa walidacji, autoryzacja, routing itd. Routing odbierze request o lajka, użyje funkcji modułu autoryzacji aby upewnić się, czy user może lajkować, potem zwaliduje, czy dane są poprawne i może poprosić osobny moduł (komunikujący się z bazą), aby dopiero on "fizycznie zalajkował" post.

komentarz 30 września 2020 przez poldeeek Mądrala (5,980 p.)
Fajna opcja z tymi middleware, żeby do każdej rzeczy zrobić oddzielną funkcję sprawdzającą. Dobrym pomysłem jest porobienie takich middlewar'ów dla ważniejszych parametrów w zależności czy przychodzą jako parametr czy w body ?
Np: ifUserExistParamsId() i ifUserExistBodyId(), ifPostExistParamsId(),  itd dla wszystkich często przesyłanych danych ?
1
komentarz 30 września 2020 przez ScriptyChris Mędrzec (190,190 p.)
Jeśli sprawdzasz daną wartość w kilku endpointach (jest to powtarzalne), to zgrupuj te walidacje w jeden middleware. Jeśli walidacja danej wartości wymaga wielu kroków to ją również wydziel do osobnej funkcji i niech middleware ich sobie używa. Możesz podzielić sobie części odnoszące się np. do walidacji i autoryzacji do osobnego modułu, w którym będą bebechy implementacyjne skupione wokół jednego kontekstu. Dokładna implementacja zależy od architektury aplikacji i założeń biznesowych.
+1 głos
odpowiedź 29 września 2020 przez Oscar Nałogowiec (29,340 p.)
Oczywiście, pamiętaj, że klient może sobie wysłać dowolny request wpisując co chce do paska przeglądarki, albo wręcz może to nie być przeglądarka tylko jakiś hakerski program...

Podobne pytania

–1 głos
2 odpowiedzi 534 wizyt
pytanie zadane 23 marca 2020 w Systemy operacyjne, programy przez michal_php Stary wyjadacz (13,700 p.)
0 głosów
1 odpowiedź 995 wizyt
pytanie zadane 24 sierpnia 2021 w Sprzęt komputerowy przez Pawel1995 Gaduła (3,810 p.)
0 głosów
0 odpowiedzi 159 wizyt
pytanie zadane 29 stycznia 2017 w Inne języki przez BiednyStudent Początkujący (250 p.)

93,327 zapytań

142,325 odpowiedzi

322,396 komentarzy

62,657 pasjonatów

Motyw:

Akcja Pajacyk

Pajacyk od wielu lat dożywia dzieci. Pomóż klikając w zielony brzuszek na stronie. Dziękujemy! ♡

Oto polecana książka warta uwagi.
Pełną listę książek znajdziesz tutaj

Wprowadzenie do ITsec, tom 1 Wprowadzenie do ITsec, tom 2

Można już zamawiać dwa tomy książek o ITsec pt. "Wprowadzenie do bezpieczeństwa IT" - mamy dla Was kod: pasja (użyjcie go w koszyku), dzięki któremu uzyskamy aż 15% zniżki! Dziękujemy ekipie Sekuraka za fajny rabat dla naszej Społeczności!

...