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?

Trochę mylisz pojęcia, ale:



Takiego czegoś nie powinieneś nigdy robić.

Dane escape'ujesz przed przesłaniem zapytania do bazy danych. Przy wyświetlaniu natomiast filtrujesz przed encjami HTML.

[cite]filtrujesz przed encjami HTML[/cite]
Przed? Co masz na myśli?

Czyli zapisywać do DB dane wejściowe od użytownika w takiej formie w jakiej podał, a dopiero podczas wyświetlania filtrować i usuwać na przykłąd kod HTML czy zamieniać znaki na encje?

Jesli w danym polu nie ma prawa byc HTML, to go wywalam przed wlozeniem do bazy.
Jesli w danym polu moze byc HTML, to nic nie robie z nim przed wlozeniem do bazy (nie licząc rzecz jasna escapowania, ale to jest z automatu podczas bindowania)

Przy wyswietlaniu:
jesli przy wyswietlaniu nie moze byc wykonywalnego HTML, to uzywam hmlspecialchars() przed wyswietleniem, niezaleznie czy wczesniej usuwalem HTML czy nie. Zadnej filozofii tu nie ma.

Tak.

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ć.

@nospor - Z kodem HTML masz rację - warto go usuwać, nawet dla tego, że niepotrzebny - zagracałby bazę danych.
@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.

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.



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

W takim razie nie zgodzę się z tym "faktem dotyczący błędu"
Skoro i tak filtr, nie przepusci tego co nie wolno to nie widze problemu, by walic to, na wypadek, jakby filtr zawiodl, bo programista źle go napisał.

Mogę. Jeśli jest jasna informacja: "tu kodu HTML nie wolno ci wpisac", to w zgodzie z sumieniem mogę go usunac, jesli user go wpisał.

Mam wrażenie, że chyba nigdy nie miałeś okazji modyfikować / rozwijać istniejącego systemu . Myślisz tylko w kategoriach "tu i teraz". Jak nadasz filtr, to za jakiś czas możesz albo chcieć go zdjąć albo zmienić jego zasadę działania i wtedy będzie lipa, bo trwale zmienionych danych nie odmienisz, a w prawidłowej implementacji, traktując dane jako informację abstrakcyjną, możesz zmieniać dowolnie sposób prezentacji i nigdy nie będzie z tym problemu.

Istnieje zasada, wedle której nie należy nigdy zakładać, że dana rzecz się nigdy nie zmieni.

To straszne.... sorki, jesli na danym etapie zakladam, ze nie ma tu byc takich danych to koniec kropka i ma ich nie byc. Nie widze sensu na pozwalanie ich wkladania tylko dlatego ze byc moze za 100 lat mi sie zachce, ze jednak bede teraz pozwalał. Ok, jak za te 100 lat zmienie zdanie i faktycznie bede pozwalał na dane, na ktore teraz nie pozwalam to w czym problem? Od tego nowego momentu te nowe dane będą sie pojawiac.

Wg Twojego toku myślenia, po grzyba w ogole zakładać walidatory na dane? Przeciez za jakis czas zachce mi sie zmienic na co pozwalam i bedzie lipa... totalny bezsens...

Twoja argumentacja do mnie nie przemawia. Do Ciebie nie przemawia moja. Ok. Oboje mamy do tego prawo, nie ma juz dalszego sensu siebie nawzajem przekonywac. adbacz poznał obie opinie, wybierze te, którą mu bardziej bedzie pasowala.

Pragnę dodać tylko 3 ostatnie rzeczy:

1.) Napisałeś sobie "100 lat", żeby umyślnie i złośliwie (?) wyolbrzymić. Jeżeli robisz stronki tylko dla siebie, to taki argument jeszcze by miał jakiś sens, natomiast przy pracy np. z klientem (albo zwyczajnie z inną osobą) nie ma tutaj żadnego zastosowania do rzeczywistości. Nie przewidzisz, co dana osoba sobie wymyśli nie za "100 lat", tylko za tydzień, dwa tygodnie, miesiąc, ..., ... Po prostu nie ma takiej możliwości.

2.) Już wiele widziałem projektów / osób, które myślały podobnie jak Ty, ale koniec końców w końcu każdy przyznawał rację, że dane powinny być traktowane w sposób abstrakcyjny. Jednym z przykładów, który ostatnio mi się nasunął na myśl jest Yii i jego niesławne defaultScope, którego po zastosowaniu w praktyce nie sposób było zmienić. Twórcy wielokrotnie na listach dyskusyjnych upierali się, że zastosowanie defaultScope "wynika z designu aplikacji" i jeżeli mamy podejrzenie, że jakaś dana może się kiedykolwiek zmienić, to po prostu nie powinno się go stosować. I tak upierali się do momentu, aż użytkownicy podawali multum przykładów sytuacji, gdzie jakaś dana względnie nie wyglądała na taką, która miałaby się kiedykolwiek zmienić, ale w końcu przychodził taki moment, że w jakiś sposób w końcu musiała się zmienić i DEVowie mieli w tym momencie ogromny problem. Twórcy Yii w końcu zrozumieli swój błąd, przyznali rację i w Yii 2.0 już nie ma jako takiego defaultScope.

3.) Jak sam już przyznałeś - koniec końców istnieje ryzyko zmiany konkretnej danej, więc teraz opcje są dwie:
- Jesteś hazardzistą - wybierasz grę na loterii, że dany sposób przepływu informacji się nigdy nie zmieni
- Jesteś DEVem - masz możliwość dowolnego i swobodnego operowania na abstrakcyjnych danych

Argumenty raczej mówią same za siebie. Teraz niech czytelnik wybiera

ad1) Chcialem poprostu pokazac za jakis czas. Rownie dobrze moze to byc 100 godzin

W miedzyczasie dodalem cos do mojej poprzedniej wypowiedzi

Masz coś tutaj do dodania?

Nie można tu czegoś "dodać", bo walidacja (np.) formularza ma się zupełnie nijak do edycji danych wysłanych przez użytkownika przed zapisem do DB. Jedno z drugim nie ma związku.

Widzę, że się upierasz mimo wszystko z bliżej nieokreślonego powodu. Nie mniej polecam Ci ad. 3 z ostatniego mojego postu (i jeżeli są chęci to pozostałe podpunkty), natomiast pozostałym czytelnikom wszystkie ad.

Ciezko sie rozmawia z osobą, ktora próbuje cie obrazac, gdy ktos inny ma inne zdanie niz ta osoba.
Jesli nie slucham Ciebie to nie jestem programistą tylko hazaradzistą. Jak slucham Ciebie to jest cool i cacy... Kurcze, jak w przedszkolu....



Widac nie zrozumiales co ci staralem sie wytlumaczyc
Na dodatek uznales, ze ja zawsze kasuje HTML i jestem "hazardzistą"... Dalsza dyskusja mnie podnozka z wielkiem DEVem nie ma sensu. Nie jestem godzien.

O Panie drogi.... no miałeś jednak rację, że się nie dogadamy. I to zdecydowanie . Ja tam na przedszkola albo ostatnio popularne gimnazja nie będę się pojedynkował, nie ma sensu wydłużać tematu "niczym"

Temat wyczerpany. Teraz pozostaje decyzja użytkownika, jakiego rozwiązania użyje

Pozdrawiam.