pyt
Q
the_foe Jak już Wojtek napisał - prepared statements i po bólu. Nie trzeba wymyślać N problemów które mogą się pojawić.
a jak sie uzywa php4?
Sensownie eskejpować tam gdzie to MA SENS, to znaczy w momencie konstruowania zapytania do bazy, a nie wszędzie gdzie tylko można - na zapas. SQL injection to problem trywialnie prosty do rozwiązania, jeśli tylko ma się pojęcie o tym, co się robi. Dodam tylko, że trzeba być chorym na umyśle, żeby wymyślić takie "zabezpieczenie" jak magic quotes w PHP. nie rozumiem czemu to jest adresowane do mnie? ;)
odp
A
Jak już Wojtek napisał - prepared statements i po bólu. Nie trzeba wymyślać N problemów które mogą się pojawić. a jak sie uzywa php4? Popularniejsze frontendy na DB, obsługują prepared statements (MDB2 i AdoDB).
odp
A
as possible. This release wraps up all the outstanding patches for the PHP 4.4 series, and is therefore the last normal PHP 4.4 release. If necessary, do czasu kiedy beda releasy i hostingi beda oferowac php4 trzeba sie liczyc z kompatybilnoscia w dol, szczegolnie jesli robi sie cos na zamowienie.
Kto dzisiaj potrzebuje aplikacji w PHP4? Naprawdę, nie potrafię sobie wyobrazić konieczności użycia tego zabytku. Co jest w czwórce czego nie ma w piątce poza ułomną obsługą XML-a i XSLT?
odp
A
nie rozumiem czemu to jest adresowane do mnie? ;)
the_foe
Brak prepared statements czy fakt korzystania z PHP4 nie zmienia faktu, że uniknięcie SQL injection jest banalnie proste, jeśli się to robi w przemyślany sposób. Rozwiązanie które podałeś z "przetrzepaniem zmiennych POST" nie jest przemyślane.
Reszta to obserwacja natury ogólnej :)