Zabrałem się za prace Inżynierską (specjalistyczny CMS)
Zacznę od tego ze moja znajomość PHP pozwala żeby go napisać
Pytanie brzmi czy moje rozwiązanie jest tym najlepszym

Parę pytań na początek:

(chodzi o wprowadzanie danych w Panelu Admina)
Walidacja formularzy
Czy sprawdzać każdą zmienną przez preg_match?
a może warto robić to w Java Script?
lub wystarczy za pomocą PDO chronić się przed sql injection, a co wprowadzi użytkownik w danym polu jest nie ważne?
a może inna metoda?

NIE. A po co? Do tego podchodzi się inaczej. Pamiętaj, że najlepsza możliwa walidacja jest wówczas gdy dokładnie wiemy czego się mamy spodziewać. Jeżeli przykładowo ma to być liczba - to preg_match jest zbędny. Staraj się "przewidywać" i planować to co użytkownik może wprowadzić - w przypadku takich rzeczy jak na przykład imię, które nie jest może tak istotne można sobie walidacje nieco uprościć ale i tak musisz zabezpieczać się przed XSS czyli eliminować wpisy zawierające podejrzane znaki - nikt przecież nie ma w imieniu znaku > ani < itd.. Tutaj przyda się preg_match.



Walidacja musi być po stronie serwera przed podaniem jej do bazy (zakładając, że używasz PDO w taki sposób by eliminować SQL-inj.). Dodanie walidacji po stronie klienta czyli javascript zależy od chęci i czasu nad projektem - należy też pamiętać, że walidacja JS musi być taka sama jak walidacja PHP i zmiana w jednej musi ciągnąć za sobą zmianę w drugiej. Jest to ogólnie zabieg pomagający użytkownikowi. Jeżeli nie chcesz robić pełnej walidacji JS to zrób przynajmniej sprawdzanie czy są wypełnione wymagane pola przed wysłaniem tego do PHP.



To podejście jest strasznie nie zdrowe - bardzo szybko okazuje się, że ludzie wpisują rozmaite głupoty a silnik MySQL przykładowo pozwala na wprowadzanie dziwnych danych innego typu pod dany typ bez wyrzucania błędów zatem zapisują się jeszcze większe idiotyzmy nie wspominając o XSS itp... Nie myśl sobie że jeśli robisz panel administracyjny dla "zaufanych" użytkowników, którzy raczej nie będą chcieli sobie samemu zrobić krzywdę, to możesz odpuścić bezpieczeństwo (nikt przecież nie będzie próbował zrobić sql-injection w panelu admina...). Jeśli ktoś niechcący dostanie się do takiego panelu to ma otwartą drogę - PA powinien zatem być porządnie zabezpieczony.

Co do innych metod poszukaj info o
filter_var
czy
validate filters

Walidację można wykonywać na wieeeele sposobów:

[PHP] pobierz, plaintext 
 
$liczba = '12345';
 
if(is_numeric($liczba)) // ...
 
if(preg_match('/^\d+$/',$liczba)); // ... totalna bzdura - ale można
 
if($liczba == (int) $liczba)) // ... 
 
// itd...
 
[PHP] pobierz, plaintext 

Wyrażenia regularne trzeba jeszcze potrafić pisać.
Na krótkim stringu, błędnie napisane wyrażenie prześlizgnie się niezauważone.
Na długim stringu zawiesi system.

Kilka przykładów:
http://blogs.msdn.com/b/bclteam/archive/20.../10/370690.aspx
http://stackoverflow.com/questions/1930135...n-large-matches

Podsumowując:
Samodzielne pisanie wyrażeń odpada o ile ktoś napisał i przetestował je wcześniej.

Zawsze polecam biblioteki PEAR. Tym razem nie będzie inaczej:
http://pear.php.net/package/Validate
Pierwsza wersja została opublikowana 2002-08-18.
Blisko 10 lat temu! Gwarancja stabilności jakiej nie znajdziesz nigdzie indziej.

Truizm, pasujący do wszystkiego: do pisania wyrażeń regularnych, do pisania obiektowego, aż w końcu do pisania programów w ogóle.


Doskonałe przykłady, które pokazują, jak nie należy pisać wyrażeń regularnych. W obu przypadkach użyto patternów, które spowodowały nieoptymalne obliczanie/dopasowywanie wyrażenia, i powodując gigantyczne zapotrzebowanie na zasoby (pamięć/cpu). Jak dla mnie jest to kwintesencja "jak nie pisać wyrażeń regularnych".


Trochę niegramatycznie, ale zakładam, że chodzi Ci o to, by nie próbować pisać wyrażeń, lecz korzystać z gotowców? No to piękny model proponujesz. Nie uczmy się sami lecz korzystajmy z gotowców. Nie piszmy prac dyplomowych sami, lecz korzystajmy z gotowców. Mało tego: zamknijmy wszystkie szkoły, po co młodych uczyć czegoś nowego (dla nich) - niech korzystają z gotowców. Dziękuję, ale to podejście dla mnie jest nieakceptowalne.

W biznesie nie ma miejsca na eksperymenty. Kod produkcyjny powinien być dobrze zdebugowany.
Praca nie musi polegać na napisaniu kazdego najdrobniejszego elementu samodzielnie, opłaca się budować z małych, dobrze przetestowanych klocków.


Truzim, tyle że na tym zdaniu nie skończyłem wypowiedzi, więc nie wiem dlaczego się przychrzaniasz.

Zgadza się, nie skończyłeś. Bo od tego zacząłeś. Poparłeś to przykładami źle napisanych wyrażeń regularnych, a na końcu podsumowałeś, że (ja tak zrozumiałem): jak nie umiesz pisać wyrażeń regularnych, to lepiej się za to nie bierz (i weź coś innego).
Tymczasem ja nie tyle "przychrzaniam się", co po prostu z takim podejściem walczę. Warto się nauczyć czegokolwiek (choćby dyskutowanych tu wyrażeń regularnych). Jest to bowiem element języka, więc elementarną wiedzę warto mieć. A czym będziemy sprawdzać dane z formularzy, to już jest inna bajka. Nie twierdzę, że regexp jest panaceum na wszystko.


Tylko że ktoś te klocki też musi zbudować (i przetestować). Zresztą, skoro ludzie robią sobie własne frameworki, nie widzę przeszkód, by samemu robić sobie zestaw funkcji/obiektów do walidacji danych z formularzy...

Co jest złego w podejściu polegającym na korzystaniu z przetestowanego softu?

Generalnie to nic. "Problemem" (choć może to nie problem, ale chwilowo brakuje mi słowa, by to poprawnie nazwać) jest to, że namawiasz do użycia Validate pomimo tego, że:
1. nie wiesz, czy w danym oprogramowaniu (Jo-Jo napisał o "specjalistycznym CMSie") Validate się sprawdzi
2. Validate to jednak nadal beta. Zawiera błędy niepoprawione od ponad dwóch lat: http://pear.php.net/bugs/bug.php?id=16897
3. dla mnie z całego pakietu Validate jedyne sensowne testy to testy IBAN i testy na poprawność emaila (choć i tu są błędy)

Nie twierdzę, że zrobiłbym to lepiej. Nie twierdzę, że te błędy są krytyczne (choć w oprogramowaniu OpenSource taki czas reakcji... kłuje w oczy). Dla mnie najistotniejsze jest, że raczej tego nie będę potrzebował. I jestem dość mocno przekonany, że Jo-Jo też nie.

P.S.
Ja kończę tę dyskusję, za bardzo odbiegła od sedna i w zasadzie wszystko już powiedziałem.

PEAR:Validate to dobre miejsce do poszukiwania odpowiedzi na pytanie jak powinna wyglądać walidacja.


Jak dla mnie to problem opisywany w tym tickecie nie jest bugiem. Kwestia gustu.
10 lat developowania i nadal wersja beta, świadczy to o ostrożności autora i potwierdza moją tezę, mianowicie nie da w któtkim czasie stworzyć stabilnego sofu i o ile jest możliwość trzeba sięgać do sprawdzonych rozwiązań. Zbór bibltiek PEAR to prowdopodobnie najlepiej sprawdzone i przetestowanie oprogramowanie PHP jakie tylko istnieje.


Patrz wyżej.

Wywołałem chyba małą wojnę
napisałem sobie taką klasę
wątpię żeby byłą idealnie ale zasadniczo rzecz biorąc to co przetestowałem to działa

[PHP] pobierz, plaintext 
<?php
class validForm
{
	public $alphabet="a-zA-ZąśćężźńłóĄŚĆĘŻŹŃŁÓ";
 
	public function alphabet($tekst=null, $min=0, $max=25 )
	{
	$w="{".$min.",".$max."}";
	   if (preg_match("/^[a-zA-ZąśćężźńłóĄŚĆĘŻŹŃŁÓ]$w$/", $tekst))
			return 1;
			else
			return 0;
	}
	public function checke($tekst=null )
	{
	      if ($tekst==1 || $tekst==FALSE)
			return 1;
			else
			return 0;
	}
	public function number($tekst=null, $min=0, $max=25 )
	{
	$w="{".$min.",".$max."}";
	   if (preg_match("/^[0-9]$w$/", $tekst))
			return 1;
			else
			return 0;
	}	
	public function price($tekst=null, $min=0, $max=25 )
	{
	$w="{".$min.",".$max."}";
	   if (preg_match("/^[0-9\,]$w$/", $tekst))
			return 1;
			else
			return 0;
	}	
	public function login($tekst=null, $min=3, $max=15 )
	{
	$w="{".$min.",".$max."}";
	   if (preg_match("/^[a-zA-Z0-9\-\_]$w$/", $tekst))
			return 1;
			else
			return 0;
	}
	public function email($tekst=null, $min=3, $max=15 )
	{
	$w="{".$min.",".$max."}";
	   if (preg_match("/^[_a-z0-9.-]*[a-z0-9]@[_a-z0-9.-]*[a-z0-9].[a-z]{2,3}$/", $tekst))
			return 1;
			else
			return 0;
	}
	public function password($tekst=null,$tekst2=null, $min=3, $max=15 )
	{
	$w="{".$min.",".$max."}";
	   if (preg_match("/^[a-zA-Z0-9\-\@\#\$\_]$w$/", $tekst))
	   		if ($tekst==$tekst2)
				return 1;
				else
				return 0;
			else
			return 0;
	}
	public function text($tekst=null, $min=0, $max=25 )
	{
	$w="{".$min.",".$max."}";
	   if (preg_match("/^[a-zA-Z0-9ąśćężźńłóĄŚĆĘŻŹŃŁÓ\s\(\)\?\:\.\,\!]$w$/", $tekst))
			return 1;
			else
			return 0;
	}
	public function adres($tekst=null, $min=0, $max=45 )
	{
	$w="{".$min.",".$max."}";
	   if (preg_match("/^[a-zA-Z0-9ąśćężźńłóĄŚĆĘŻŹŃŁÓ\s\-\/\\\.\(\)\?]$w$/", $tekst))
			return 1;
			else
			return 0;
	}
	public function kod($tekst=nul)
	{
 
	   if (preg_match("/[a-zA-Z0-9ąśćężźńłóĄŚĆĘŻŹŃŁÓ\s\(\)\<\>\/\?\%\"\}\{\_\'\=\&\;\*\$\#\:\.\,\-]$/", $tekst))
			return 1;
			else
			return 0;
	}
	public function mobilephone($tekst=null, $min=0, $max=12 )
	{
	$w="{".$min.",".$max."}";
	   if (preg_match("/^[0-9\s]$w$/", $tekst))
			return 1;
			else
			return 0;
	}
	public function phone($tekst=null, $min=0, $max=9 )
	{
	$w="{".$min.",".$max."}";
	   if (preg_match("/^[0-9\s]$w$/", $tekst))
			return 1;
			else
			return 0;
	}
	public function pesel($tekst=null, $min=0, $max=11 )
	{
	$w="{".$min.",".$max."}";
	   if (preg_match("/^[0-9\s]$w$/", $tekst))
			{
				 $suma=($tekst[0]*1)+($tekst[1]*3)+($tekst[2]*7)+($tekst[3]*9)+($tekst[4]*1)+($tekst[5]*3)+($tekst[6]*7)+($tekst[7]*9)+($tekst[8]*1)+($tekst[9]*3);
				 $suma=$suma%10;
				 $suma=10-$suma;
				# if ($suma==$tekst[10])
				if (10==10)
					{
						$rok = substr($tekst,0,2);
						$miesiac = substr($tekst,2,2);
						$dzien = substr($tekst,4,2);
						if ($tekst[0]==0)
						{
						$rok="20".$rok;
						$miesiac=$miesiac-20;
						}
						else
						{
 
						$rok="19".$rok;
 
						}
							if (checkdate($miesiac ,$dzien ,$rok))
							return 1;
							else
							return 0;
 
 
					}
					else
					return 0;
 echo $suma;
			}
			else
			return 0;
	}
 
}
?>
[PHP] pobierz, plaintext 

Ja wysiadam.
Skrypty muszą być odporne na zmiane kodowania, nie mogą zawierać polskich znaków!
Tylko ASCII.

Etam "wojnę". Po prostu mała różnica zdań
@wNogachSpisz już jedną rzecz napisał, ja dołożę kilka uwag:
1. funkcja number zwróci fałsz dla liczb ujemnych i ułamkowych - to zgodne z Twoimi założeniami?
2. funkcja price zadziała TYLKO dla przecinka "," jako separatora części całkowitej i ułamkowej. Tak miało być?
3. funkcja email wyłoży się na adresach mailowych z wielkimi literami (a taki adres jest całkowicie poprawny). Ponadto tłucze mi się po łbie (ale uciąć sobie go nie dam), że:
a) fragment adresu mailowego przed "@" powinien zaczynać się od litery
domena powinna zaczynać się od litery
Tak czy inaczej, jeśli na siłę chcesz wyrażenie regularne, które zweryfikuje adres mailowy, to przeszukaj forum na okoliczność słowa "weryfikacja adresu email" lub podobnych - na pewno był ładny, kilkulinijkowy regexp
4. funkcje phone i mobilephone wyglądają mi na identyczne I obie wyłożą się zarówno na separowaniu spacją lub myślnikiem (111-111-111), jak i na międzynarodowej notacji telefonicznej: +48 22 111 1111 (ze znakiem plusa)

Nie zwróciłem uwagi ale mimo wszystko liczby i tak zawsze będą dodatnie
panuje zmienić na is_numeric()


wydaje mi się że tak będzie lepiej i zawsze będę miał spójne dane w bazie


planuje poprawić na
filter_var($_POST["email"], FILTER_VALIDATE_EMAIL)
co do domeny można normlanie rejestrować domeny które mają cyfrę na początku


muszę dopracować


Co do kolegi wNogachSpisz
geniuszem nie jestem wszystkie rozwiązania jakie znalazłem na walidacje polskich liter właśnie tak wyglądały
i o ile kody ASCII liter sobie wyciągnę, to nie wiem jak je zastosować w preg_match

Pozdrawiam

Smutne ale prawdziwe. Jakość sniptów produkcji krajowej jest zatrważająca.


Musisz zrobić normalizację UTF-8, a potem już z górki :-]

Gotowca nie dam, ale polskie znaki usuwam tym sposobem:

[PHP] pobierz, plaintext 
<?php
 
require 'I18N/UnicodeNormalizer.php';
$normalizer = new I18N_UnicodeNormalizer(); // z PEAR
 
function diacritic_replace( $s ) {
 
	global $normalizer;
 
	// maps German (umlauts) and other European characters onto two characters before just removing diacritics
	$s    = preg_replace( '@\x{00c4}@u'    , "AE",    $s );    // umlaut � => AE
	$s    = preg_replace( '@\x{00d6}@u'    , "OE",    $s );    // umlaut � => OE
	$s    = preg_replace( '@\x{00dc}@u'    , "UE",    $s );    // umlaut � => UE
	$s    = preg_replace( '@\x{00e4}@u'    , "ae",    $s );    // umlaut � => ae
	$s    = preg_replace( '@\x{00f6}@u'    , "oe",    $s );    // umlaut � => oe
	$s    = preg_replace( '@\x{00fc}@u'    , "ue",    $s );    // umlaut � => ue
	$s    = preg_replace( '@\x{00f1}@u'    , "ny",    $s );    // ń => ny
	$s    = preg_replace( '@\x{00ff}@u'    , "yu",    $s );    // ˙ => yu
 
	// maps special characters (characters with diacritics) on their base-character followed by the diacritical mark
	// exmaple:  � => U�,  � => a`
 
	$s = $normalizer->normalize($s, 'NFD', 'UTF-8');
 
	$s    = preg_replace( '@\pM@u'        , "",    $s );    // removes diacritics
 
	$s    = preg_replace( '@\x{00df}@u'    , "ss",    $s );    // maps German � onto ss
	$s    = preg_replace( '@\x{00c6}@u'    , "AE",    $s );    // Ć => AE
	$s    = preg_replace( '@\x{00e6}@u'    , "ae",    $s );    // ć => ae
	$s    = preg_replace( '@\x{0132}@u'    , "IJ",    $s );    // ? => IJ
	$s    = preg_replace( '@\x{0133}@u'    , "ij",    $s );    // ? => ij
	$s    = preg_replace( '@\x{0152}@u'    , "OE",    $s );    // Π=> OE
	$s    = preg_replace( '@\x{0153}@u'    , "oe",    $s );    // œ => oe
 
	$s    = preg_replace( '@\x{00d0}@u'    , "D",    $s );    // Đ => D
	$s    = preg_replace( '@\x{0110}@u'    , "D",    $s );    // Đ => D
	$s    = preg_replace( '@\x{00f0}@u'    , "d",    $s );    // đ => d
	$s    = preg_replace( '@\x{0111}@u'    , "d",    $s );    // d => d
	$s    = preg_replace( '@\x{0126}@u'    , "H",    $s );    // H => H
	$s    = preg_replace( '@\x{0127}@u'    , "h",    $s );    // h => h
	$s    = preg_replace( '@\x{0131}@u'    , "i",    $s );    // i => i
	$s    = preg_replace( '@\x{0138}@u'    , "k",    $s );    // ? => k
	$s    = preg_replace( '@\x{013f}@u'    , "L",    $s );    // ? => L
	$s    = preg_replace( '@\x{0141}@u'    , "L",    $s );    // L => L
	$s    = preg_replace( '@\x{0140}@u'    , "l",    $s );    // ? => l
	$s    = preg_replace( '@\x{0142}@u'    , "l",    $s );    // l => l
	$s    = preg_replace( '@\x{014a}@u'    , "N",    $s );    // ? => N
	$s    = preg_replace( '@\x{0149}@u'    , "n",    $s );    // ? => n
	$s    = preg_replace( '@\x{014b}@u'    , "n",    $s );    // ? => n
	$s    = preg_replace( '@\x{00d8}@u'    , "O",    $s );    // Ř => O
	$s    = preg_replace( '@\x{00f8}@u'    , "o",    $s );    // ř => o
	$s    = preg_replace( '@\x{017f}@u'    , "s",    $s );    // ? => s
	$s    = preg_replace( '@\x{00de}@u'    , "T",    $s );    // Ţ => T
	$s    = preg_replace( '@\x{0166}@u'    , "T",    $s );    // T => T
	$s    = preg_replace( '@\x{00fe}@u'    , "t",    $s );    // ţ => t
	$s    = preg_replace( '@\x{0167}@u'    , "t",    $s );    // t => t
 
	// remove all non-ASCii characters
	$s    = preg_replace( '@[^\0-\x80]@u'    , "",    $s ); 
 
	return $s;
}
[PHP] pobierz, plaintext 

tylko jedna korekta do dyskusji


@abort::od kiedy domena musi sie zaczynac od litery??

sprawdz np.: 1.pl , 2.pl itd..

j.

Nie wiem dlaczego mnie zaćmiło, ale faktem jest, że to co napisałem o domenach, nie jest prawdą. Tobie dzięki za naprostowanie a innych przepraszam, jeśli wprowadziłem w błąd. Sorry.