Walidacja wprowadzania danych zawsze była dla mnie dość wewnętrzną walką.
Na progu dodania prawdziwej struktury bezpieczeństwa i kodu do naszego starszego projektu przepisania aplikacji (która do tej pory prawie utrzymuje mocny stary kod bezpieczeństwa i sprawdzanie poprawności danych), ponownie zastanawiam się, ile powinienem zweryfikować, gdzie itp
Przez 5 lat pracy jako profesjonalny programista Java stworzyłem i udoskonaliłem moje osobiste zasady dotyczące sprawdzania poprawności wprowadzania danych i środków bezpieczeństwa. Gdy chcę ulepszyć swoje metody, chciałbym usłyszeć od was kilka pomysłów. Ogólne zasady i procedury są w porządku, a także specyficzne dla Javy.
Podsumowując, są to moje wytyczne (dostępne w 3-warstwowym stylu aplikacji internetowej) z krótkimi objaśnieniami:
1. strona klienta (przeglądarka): minimalna walidacja, tylko niezmienne reguły (obowiązkowe pole e-mail, należy wybrać jeden element i tym podobne); stosowanie dodatkowej walidacji, takiej jak „od 6 do 20 znaków” rzadziej, ponieważ zwiększa to prace konserwacyjne przy zmianach (można je dodać, gdy kod biznesowy jest stabilny);
Strona serwera pierwszego poziomu (obsługa komunikacji internetowej, „kontrolery”): Nie mam reguły dla tego, ale uważam, że należy obsługiwać tylko błędy manipulacji danymi oraz błędy montażu / analizy (pole urodzin nie jest prawidłową datą); dodanie tutaj dodatkowej weryfikacji sprawia, że jest to naprawdę nudny proces;
2. poziom (warstwa biznesowa): solidna walidacja, nie mniej; format danych wejściowych, zakresy, wartości, wewnętrzne sprawdzanie stanu, czy metoda nie może zostać wywołana w dowolnym momencie, role / uprawnienia użytkownika itd .; użyj jak najmniejszej ilości danych wejściowych użytkownika, w razie potrzeby pobierz je ponownie z bazy danych; jeśli weźmiemy pod uwagę pobrane dane z bazy danych również jako dane wejściowe, sprawdziłbym je tylko wtedy, gdy wiadomo, że niektóre dane są niewiarygodne lub wystarczająco uszkodzone w DB - silne typowanie wykonuje tutaj większość pracy, IMHO;
Trzecia warstwa (warstwa danych / DAL / DAO): nigdy nie uważałem, że potrzebna jest tutaj duża walidacja, ponieważ tylko warstwa biznesowa powinna mieć dostęp do danych (może to sprawdzić w niektórych przypadkach, np. „Param2 nie może być pusty, jeśli param1 jest prawdziwy”); zauważ jednak, że kiedy mam na myśli „tutaj” mam na myśli „kod, który uzyskuje dostęp do bazy danych” lub „metody wykonujące SQL”, sama baza danych jest zupełnie odwrotna;
baza danych (model danych): musi być tak przemyślana, silna i samowykonująca, aby w jak największym stopniu unikać niepoprawnych i uszkodzonych danych w bazie danych, z dobrymi kluczami głównymi, kluczami obcymi, ograniczeniami, typem danych / długością / rozmiarem / precyzja i tak dalej - nie uwzględniam wyzwalaczy, ponieważ mają oni swoją prywatną dyskusję.
Wiem, że wczesna walidacja danych jest przyjemna i pod względem wydajności, ale powtarzana walidacja danych jest nudnym procesem i przyznaję, że sama walidacja danych jest dość denerwująca. Dlatego tak wielu programistów pomija go lub robi to w połowie. Ponadto każde zduplikowane sprawdzanie poprawności jest możliwym błędem, jeśli nie są one synchronizowane przez cały czas. To są główne powody, dla których obecnie wolę pozwolić większości walidacji na warstwę biznesową, kosztem czasu, przepustowości i procesora, wyjątki obsługiwane osobno dla każdego przypadku.
Więc, co o tym myślisz? Przeciwne opinie? Czy masz inne procedury? Odniesienie do takiego tematu? Każdy wkład jest ważny.
Uwaga: jeśli myślisz o robieniu rzeczy w Javie, nasza aplikacja jest oparta na Spring z Spring MVC i MyBatis (wydajność i zły model bazy danych wykluczają rozwiązania ORM); Planuję dodać Spring Security jako naszego dostawcę zabezpieczeń oraz JSR 303 (Hibernate Validator?)
Dzięki!
Edycja: dodatkowe wyjaśnienia na 3. warstwie.