![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 532 Pomógł: 24 Dołączył: 15.04.2011 Skąd: Kalisz Ostrzeżenie: (0%) ![]() ![]() |
Próbowałem już różnych filtrowań, w różnych momentach działania aplikacji lecz żaden nie spełniał moich oczekiwań - zawsze było coś co nie działało tak jak powinno.
Kiedy i jak bardzo filtrować dane pochodzące od użytkownika? Nie mówie tutaj o Froncie - bo tutaj filtruje zawsze wszystko i nie ma zmiłuj. 1. Od razu podczas pobierania danych z POST? - ok, zapisuję takie dane w DB i przefiltrowane dane mają encje HTML, które później sa w wielu miejscach wyświetlane, ale równeż w tytule paska przeglądarki, co czasami sprawia, że zamiast apostrofu mam encję widczną i muszę to naprawiać funkcją htmlspecialchars_decode. 2. Zapisywać dane czysto pobrane od usera ale filtrować dopiero podczas wyświetlania? - zapisuję do bazy za pomocą nakładki na PDO więc wykonuje escape wartości, ale trzeba byłoby pamiętać, że wyświetlana wartość, na przykład tytuł strony musi być przefiltrowana na stronie, by usunąć znaczniki HTML (by ktoś nie stwierdził, że ładnie będzie tytuł pochylić). 3. Filtrować tylko i wyłącznie kod HTML a całą resztę zostawić i filtrować podczas wyświetlania. Ale to jest wyjście podobne do punktu drugiego. Jak wy to rozwiązujecie w swoich aplikacjach? |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Moderatorzy Postów: 36 559 Pomógł: 6315 Dołączył: 27.12.2004 ![]() |
Cytat Co więcej nie rób również nigdy tak jak napisał @nospor. Dane są pojęciem abstrakcyjnym. Nie zmieniasz danych użytkownika trwale, tylko decydujesz w warstwie prezentacyjnej jak te dane mają wyglądać / być wyświetlane. Nie zgodzę się z tą opinią. Jesli dana dana nigdy ma nie być kodem HTML, nawet wyswietlanym, to można spokojnie ją wyczyścić z niego. Zresztą po to się robi walidacje danych przed wlozeniem do bazy, by nawet nie dopuścic do sytuacji, gdzie trzeba tę daną wyczyścić.
|
|
|
![]()
Post
#3
|
|
Grupa: Zarejestrowani Postów: 2 148 Pomógł: 230 Dołączył: 26.03.2008 Ostrzeżenie: (0%) ![]() ![]() |
Nie zgodzę się z tą opinią. Jesli dana dana nigdy ma nie być kodem HTML, nawet wyswietlanym, to można spokojnie ją wyczyścić z niego. Zresztą po to się robi walidacje danych przed wlozeniem do bazy, by nawet nie dopóścic do sytuacji, gdzie trzeba tę daną wyczyścić. Szczerze mówiąc to nie jest subiektywna opinia, tylko fakt dotyczący błędu, który wyjdzie przy każdym większym (i zarówno przy mniejszych) projekcie. Nie możesz decydować za użytkownika co on wpisuje. To wynika zarówno z prawidłowego przepływu informacji w systemie jak i pojęcia abstrakcyjności danych. Nie można robić tego dokładnie z tego samego powodu, dla którego nie cenzurujesz np. komentarza przy dodawaniu do DB, tylko przy wyświetlaniu. Jedyne co możesz zrobić to na poziomie walidacji poinformować użytkownika, że przesłana forma danych nie jest zgodna z wymogami systemu lub zezwolić użytkownikowi na przesłanie danych i w systemie zadecydować, jak ta dana jest prezentowana. @pyro - Zaletą tego jest to, że później operuję w marę na czystych danych od usera i robię z nimi co chcę i jak chcę, z drugiej strony jednak trzeba zawsze pamiętać, by dane filtrować przed wyświetleniem. W odpowiednio zaplanowanym systemie biała listą decydujesz, na które dane chcesz sobie pozwolić i nie musisz o tym pamiętać. Biała lista > czarna lista Ten post edytował pyro 18.11.2014, 17:49:22 |
|
|
![]() ![]() |
![]() |
Aktualny czas: 10.10.2025 - 20:05 |