Laborator 1 WAMP

Groupware

Cuprins

Aplicaţiile web şi tehnologiile groupware...................................................................................................2

Apache Web Server ..........................................................................................................................................6
Serverul de baze de date MySQL ...................................................................................................................7
WAMP .........................................................................................................................................................7
Elemente de bază în configurarea Apache....................................................................................................8
Elemente avansate de administrarea a server-ului Apache ........................................................................11
Virtual Hosts .............................................................................................................................................13
Utilizarea .htaccess .....................................................................................................................................15
Exerciții.........................................................................................................................................................17
Posibile teme pentru acasă...........................................................................................................................17
 2

Aplicaţiile web şi tehnologiile groupware

Adoptarea tehnologiilor colaborative tinde să devină în ultima perioadă o realitate şi la
nivelul organizaţiilor mici şi mijlocii care nu-şi pot permite investiţii majore în soluţii software
consacrate cum ar fi aplicaţia client-server oferită de IBM - Lotus Domino/Notes. Astfel, decizia
managerială în privinţa mediului colaborativ susţinut de tehnologii ITC este strict legată de
costurile de implementare şi de întreţinere ale produselor software. O soluţie la problema
costurilor este oferită de către aplicaţiile web. În ingineria software, o aplicaţie web sau webapp
este o aplicaţie care este accesată prin intermediul unui browser web într-o reţea, cum ar fi
Internetul sau intranetul.
Principalul avantaj adus de acest tip de aplicaţii este larga raspândire a browser-elor şi
costul lor scăzut sau chiar zero. Astfel, printre cele mai cunoscute browsere utilizate sunt:
Internet Edge (SO Windows), Mozilla Firefox 87, Opera 78, Safari 5 (dezvoltat iniţial pentru
MacOS, disponibil în prezent şi pentru Windows), Google Chrome 93. Dintre acestea,
majoritatea sunt produse software freeware, iar Mozilla Firefox este aplicaţie open-source.
Pentru un clasament al cotelor de piaţă deţinute de fiecare b rowser: pentru utilizatorii de sisteme
desktop, pentru utilizatorii de dispozitive mobile.
World Wide Web-ul a schimbat încă de la apariţia sa, la începutul anilor ’90, percepţia publică
asupra CE înseamnă Internet şi asupra beneficiilor pe care această reţea le poate aduce
diverselor medii. Toate aceste schimbări în lumea IT au avut implicaţii în domeniul economic,
social, politic şi nu numai. WWW-ul a devenit cel mai cunoscut şi utilizat serviciu internet.
Începând de la publicaţii economice, motoare de căutare, reţele sociale, magazine virtuale, blog-
uri, până la informaţii din sfera militară, a deciziilor luate în diverse instituţii ale statului, plata
impozitelor sau amenzilor, toate aceste elemente au ca şi canal de distribuţie a informației web-
ul şi principiul său de bază: hypertext-ul. Evoluţia acestui serviciu internet a fost marcată de
apariţia unui termen nou: Web 2.0. Termenul a apărut în diverse lucrări încă din 1999, dar a
fost făcut celebru de O'Reilly Media şi MediaLive in 2004, la o primă conferinţă Web 2.0. Acest
termen nu înseamnă o a doua versiune a serviciului sau o a doua versiune a modalităţilor de
realizare a paginilor web, ci marchează trecerea de la paginile web statice, cu rol strict informativ,
la paginile web interactive, centrate pe colaborare, pe comunicare şi schimb de informaţii între
utilizatori, pe conținut ce poate fi modificat chiar de utilizatori. Aplicaţii ale acestui nou curent
pot fi considerate wiki-urile, reţelele sociale, blog- urile, site-urile de partajare a fişierelor media,
aplicaţiile web, fluxurile de date RSS, etc.
 3

Figura nr. 1a Web 2.0 tag cloud

Figura nr. 1b Evolutia Web

Aplicațiile web sunt din ce în ce mai utilizate în cazul dispozitivelor mobile. Marele avantaj
al acestora este dat de suportul standardizat pentru crearea interfeței utilizator, utilizând browser-
ul mobil deja instalat pe respectivul echipament pentru randare. Mai mult decât atât, crearea de
aplicații web mobile constituie un prim pas în portabilitatea produselor software între platforme
mobile (IOS, Android) și între diverse mărci de dispozitive. Tehnologiile utilizate pentru aceste
aplicații sunt simple și cunoscute de mulți dezvoltatori: Java Script, CSS, HTML (în special
 4

HTML5). Dezvoltatorii sunt ajutați de librării precum Sencha Touch, jQuery Mobile,
PhoneGAP (utilizat în împachetarea aplicațiilor) și de API- urile dispozitivelor care pot fi apelate
din codul Java Script. Arhitectura unei asemenea aplicații poate fi observată în Figura nr. 2.
Există, într-adevăr, discuții între dezvoltatori privind modul în care aplicațiile web mobile pot
înlocui aplicațiile native scrise în Java sau Objective C (Android și iOS). Majoritatea acestora
consideră însă că nu concurența, ci complementaritatea poate descrie cel mai bine relația dintre
tehnologii. Pentru dezvoltare rapidă, portabilitate și standardizare în UI putea alege prima
categorie, iar în cazul în care aplicația noastră presupune un nivel sporit de integrare cu API
urile dispozitivului mobil sau are nevoie de elemente grafice speciale, alegerea unei aplicații
native este cea potrivită.

Figura nr. 2 Aplicatie web mobila

Revenind la aplicațiile web, trebuie reținut faptul că tocmai accesul facil cu un client
light, browser-ul web, constituie marele lor avantaj. Accesul facil se traduce prin lipsa unor pași
de instalare (cu excepția unor plugin-uri, în mod excepțional) dar și cerințele scăzute asupra
sistemului pe care rulează clientul. Aplicația web este rezidentă pe un server web care, la rândul
lui, poate fi conectat la un server de aplicații și/sau la o bază de date. Pe lângă acestea, serverul
web poate oferi acces la surse externe de date cât și la sistemul de fișiere. În general, arhitectura
unei aplicații web poate fi definită pe trei straturi: prezentare, aplicație și persistență.
Limbajele de programare/scripting utilizate în dezvoltarea de aplicații web pot fi atât client-
side (executate pe mașina client de către browser) sau server-side (executate de către serverul
web). În prima categorie regăsim HTML, CSS, Java Script, Flash, Silverlight, Java, VbScript, iar
în ce de-a doua, printre cele mai populare, PHP, JSP, Asp.Net, Phyton. Paginile pe care serverul
web le poate livra clientului pot fi statice sau dinamice, în funcție de prezența sau absența codului
 5

server-side. Astfel, dacă paginile web nu conțin cod de tip server-side, ele sunt livrate direct
clientului, fără interpretare. În caz contrar, serverul web execută operațiunile descrise de limbajele
server-side (conexiuni la baza de date, interogări, calcule complexe) și apoi oferă în format
HTML rezultatul acestora. În cazul operațiilor din partea clientului, browser-ul web interpretează
și execută operațiile definite de limbajele de scripting (JS, VbScript), pe care le aplică elementelor
interfeței definite în HTML. Aceasta din urmă este formatată conform fișierelor CSS în funcție
de stilurile alese de dezvoltator. Trebuie reținut și faptul că utilizând opțiunea view source,
utiizatorul final poate avea access la codul sursă a paginii web așa cum este el transmis
browser-ului. Mai exact, logica definită în Java Script sau alt limbaj echivalent, este în totalitate
vizibilă celor care accesează aplicația web. Pe de altă parte, limbajul server-side (PHP, JSP)
este ascuns utilizatorului, oferindu-se doar o interpretare, un rezultat al acestuia în urmă
procesării.
Dacă până în urmă cu câțiva ani delimitarea era clară între atribuțiile codului server-side și
cel client-side, tehnologiile precum AJAX, web services, librăriile complexe (jQuery) permit
codului client să acceseze baza de date, în special pentru crearea de pagini web de tip asincron.
Aceste tehnologii permit trimiterea și primirea de date de la serverul web sau chiar de la serverul
de baze de date fără a fi necesară reîncărcarea paginii web. Acest lucru se traduce printr-o
experiență îmbunătățită pentru utilizator și printr-un trafic mai redus de date. Arhitectura unei
aplicații web standard, poate fi observată în Figura nr. 3.

Figura nr. 3 Arhitectura aplicatie web

Pe lângă avantajele menționate anterior, există, bineînțeles, și dezavantaje care trebuie luate în
considereare atunci când trebuie decisă implementarea unui sistem sub formă de aplicație web:
- Conexiunea la rețea sau chiar Internet sunt necesare pentru rularea aplicației;
- Nu sunt utilizate complet resursele sistemului de calcul;
 6

- Calitatea conexiunilor influențează experiența utilizatorilor.

În continuarea acestui suport de laborator vom prezenta câteva elemente de utilizare și
administrare a celui mai popular server web, Apache.

Apache Web Server

Pentru a avea acces la aplicaţiile web de care aminteam anterior, avem nevoie de un
server web. Un server web poate fi definit ca o aplicaţie informatică, rezidentă de obicei pe
un server dedicat, care oferă conţinut informaţional, în cele mai multe cazuri o pagina web, la
cererea unui program client, în cazul nostru, la cererea unui browser. Pe lângă documentele
HTML, serverul web oferă şi fişiere de tip imagine, video, animaţii flash, scripturi, appleturi,
etc. De asemenea, serverul web, primeşte informaţii de la client (browser). Aceste informaţii
sunt rezultatul unui input realizat de utilizatori prin intermediul formularelor (ex: cu ajutorul
metodelor post). Aceste informaţii pot fi informaţii brute, sau interpretări ale acestora, realizate
de scripturi client-side, cum ar fi scripturi Java sau Action Scripturi Flash.
O altă funcţie pe care serverele web o îndeplinesc este interpretarea documentelor scrise
în limbaje server-side. Mai exact, serverul primeşte o cerere prin intermediul protocolului HTTP.
În funcţie de parametrii cererii, prin interpretarea unui script server-side, serverul web oferă
browser-ului o pagină web dinamică, cu un conţinut adecvat contextului cererii. Cele mai
cunoscute limbaje server-side sunt PHP, Perl, Asp.Net sau JSP. Aceste limbaje utilizează un
protocol denumit CGI (Common Gateway Interface) pentru conţinut dinamic. Una dintre
tehnicile de dezvoltare ale paginilor web ce utilizează comunicarea cu resursele server-side,
pentru a genera conţinut dinamic, interoga baze de date, interpreta fisiere XML, fără a reîncărca
întreaga pagină web este Ajax. Cel mai cunoscut server web, şi în acelaşi timp cel mai utilizat,
este serverul web open source Apache HTTP Server. Acest server este dezvoltat de
comunitatea Apache Software Foundation şi este oferit sub termenii unei licenţe publice,
compatibilă cu GNU (General Public License), garantând astfel dreptul de utilizare liberă a
aplicaţiei, de modificare şi de distribuţie. Serverul Apache este dezoltat pornind de la unul dintre
primele server web, NCSA HTTPd, şi a apărut în anul 1996.
Momentan, serverul este la versiunea stabilă 2.4.41 (version 32/64bits), iar cota de piaţă la
nivel global deținută de Apache la nivelul lunii sep. 2021 este 25%, fiind surclasat de Nginx,
care detine 36%. Întrucât vom utiliza în cadrul acestui laborator atât Apache cât și serverul de
baze de date MySQL (legătura între acestea fiind asigurată de limbajul server-side PHP), nu vom
apela la o instalare Apache independentă, ci la un pachet de tip AMP.
 7

Serverul de baze de date MySQL

Utilizarea bazelor de date relaţionale în proiectarea aplicaţiilor web este o tehnică larg
răspândită în rândul dezvoltatorilor de aplicaţii. Aşa cum aţi aflat la disciplina Baze de date,
acestea au ca fundament algebra relaţională şi procesul de normalizare. Majoritatea datelor
manipulate de aplicaţiile web din sfera aplicaţiilor groupware sunt stocate de către servere de
baze de date relaţionale şi sunt obţinute cu ajutorul limbajului SQL. Avantajul major al folosirii
acestui tip de server este uşurinta accesului la date chiar şi atunci când dezvoltatorul nu deţine
cunoştinţe solide de normalizare sau algebră relaţională.
Plecând de la premisa ca în următoarele laboratoare vom “întâlni” aplicaţii web exclusiv
open-source, putem preciza faptul că serverele de baze de date utilizate în dezvoltarea acestor
aplicaţii sunt, în majoritatea cazurilor, MySQL şi PostgreSQL. Ambele produse informatice
sunt aplicaţii de tip freeware şi deţin cotele de piaţă cele mai mari în rândul SGBD-urilor open-
source. MySQL apare pe piaţă în anul 1995 şi a fost dezvoltata iniţial de compania MySQL
AB din Suedia. În urma unor tranzacţii, MySQL a trecut în proprietatea Sun Microsystems
(2008), cumpărată apoi în 2009 de Oracle. Pe lângă versiunea MySQL open- source denumită
de către producător MySQL Community Server, există şi o versiune de software proprietar
denumită MySQL Enterprise, versiunea comercială, care aduce în plus pe lângă serviciile de
suport, module de monitorizare a performanţelor, de analiză a interogărilor, module de alertare
tehnică şi module de administrare profesională.

WAMP
Pentru a dezvola şi întreţine o aplicaţie web open-source, una dintre soluţiile tehnice
posibile ar fi configurarea unui sistem ce ar avea ca şi componente serverul web Apache în
cadrul căruia să fie activat modulul de recunoaştere şi interpretare a limbajul server-side PHP
şi de serverul de baze de date relaţional MySQL, versiunea Community. Soluţia descrisă
anterior este folosită de majoritatea organizaţiilor, cu menţiunea că, un mare procent dintre
aceste organizaţii aleg ca şi sistem de operare tot un produs open-source, şi anume una dintre
distribuţiile de Linux. Instalarea celor două servere, Apache şi MySQL poate fi facută şi
independent, dar, pentru a uşura munca administratorilor de sistem, începând cu anul 1998 au
apărut pachetele software de tip AMP. Acronimul provine de la inițialele Apache, MySQL şi
limbajul server-side PHP. De multe ori însă, în funcţie de cerinţele sistemului, P-ul poate
reprezenta limbajele Perl sau Phyton. Aceste pachete software ce permit o instalare facilă sunt
disponibile în forme specifice sistemului de operare ales. Astfel, pentru Linux amintim LAMP,
pentru Windows amintim WAMP, iar pentru multiplatforme amintim XAMPP. Pentru
instalarea specifica acestui laborator, vom utiliza pachetul WAMP. Unul dintre avantajele
 8

acestui pachet este prezenţa utilitarului PHPMyAdmin, program cu interfaţă grafică intuitivă
ce permite administrarea serverului de baze de date relaţională MySQL, alftel decât utilizând
exclusiv linia de comandă. Kit-ul de instalare a pachetului WAMP, ce conţine Apache 2.4,
MySQL 5.7, PHP 5.6, şi PhpMyAdmin 4.9, se poate accesa pe website-ul WampServer sau,
intr-o versiune, pe moodle.FEAA.
Timpul de download poate varia în funcţie de calitatea conexiunii Internet, dar nu ar
trebui să solicite mai mult de 15-20 sec.e
Atenţie! Ca prerechizit, asigurați-vă că ați instalat Visual C++ Redistributable pentru Visual
Studio 2012.
După executarea fișierului descărcat, se acceptă excepția de securitate “aruncată” de
Windows și termenii EULA. După menţionarea folder-ului de instalare, programul solicită
precizarea browser-ului implicit folosit. Acest lucru poate fi realizat prin alegerea executabilului
"C:\Program Files\Mozilla Firefoxe\firefox.exe", în cazul utilizării Mozilla Firefox sau
"C:\Program Files\Internet Explorer\iexplore.exe", în cazul utilizării Internet Explorer. Dacă
nu se precizează niciun browser, installer-ul va continua cu cel implicit. În final, se va
“menţiona” sistemului de operare ca firewall-ul (în cazul în care este activat) să permită accesul
în reţea a serverului web Apache. După instalare, din Start – All Programs – WampServer se
alege opţiunea Start WampServer. Iconiţa asociată WAMP se regăsește în bara de sarcini dîn
dreapta jos. Configurarea server-ului şi accesul la diverse opţiuni se realizează din meniul
aplicației instalate.

Figura nr. 4 Meniu WAMP

Elemente de bază în configurarea Apache

Pornirea serviciilor se va realiza utilizând opţiunea Start All Services din meniul
contextual. În cazul în care serverul nu porneste în starea Online, vom utiliza opţiunea Put
Online. Porturile utilizate de serverul web Apache sunt în mod implicit 80 şi 443, ultimul
 9

fiind folosit în cazul transmisiunilor securizate de tip SSL. Cel mai bun mod de a testa
funcţionalitatea serverului web este prin testarea portului 80. Acest lucru poate fi făcut din
meniul contextual WampServer – Apache –Service –Test port 80. Răspunsul în cazul
funcţionării normale ar trebui să fie unul de forma: “Your port 80 is actually used by Sever:
Apache/ 2.4.xx <Win32> PHP/5.x”. O altă modalitate este să deschidem pagina localhost.
Putem face acest lucru ori scriind adresa “localhost” sau “127.0.0.1” în orice browser, ori
alegând opţiunea localhost din meniul contextual WampServer. Pentru inceput, ar trebui sa
fie prezentă pagina server configuration. Principala modalitate de configurare a serverului
web Apache instalat local este prin editarea fişierului htppd.conf. Fişierul de configurare
deschis conţine informaţii generale despre serverul web instalat local, iar setările lui se regăsesc
la nivelul fiecărei componente dacă aceasta nu le suprascrie. Trebuie menționat că nu toate
modulele server-ului Apache se activează odată cu instalarea. Ele pot fi adăugate ulterior din
meniul wamp sau prin decomentarea liniei corespunzătoare din fișierul httpd.conf. În
continuare, câteva setări de bază care pot fi aplicate serverului Apache.
a) Schimbarea adresei IP şi a port-ului pe care serverul web răspunde solicitărilor. În situaţia
în care maşina gazdă deţine mai multe conexiuni în reţea, deci mai multe IP-uri, în cadrul
acestor setări se va specifica acest lucru. De asemenea, în cazul definirii unor servere web
virtuale, în mod implicit, setările sunt de forma…
Listen 80
dar pot fi schimbate prin specificarea adresei şi portului in (IP:PORT)…
Listen 192.168.0.10:80
b) Setarea numelui serverului şi portului pe care acesta răspunde este, deasemenea, un pas
obligatoriu în cazul unui server public. În cazul în care deţinem un DNS înregistrat, acesta poate
fi menţionat. Dacă nu există un domeniu, se va specifica IP-ul serverului. Spre exemplu, dacă
administratorul domeniului www.aplicatii-mobile.ro dorește să-şi gestioneze propriul server
web, va folosi următoarea setare (trebuie luat în calcul şi timpul de propagare a domeniului în
tabelele DNS)
ServerName aplicatii-mobile.ro:80
c) Setarea email-ului administratorului serverului web. Pe paginile de eroare generate în
mod automat (cod 404, 403) apare de obicei această adresa de email pe care utilizatorii o
pot folosi pentru a afla informaţii. În mod implicit, aceasta este admin@localhost, dar este
importantă schimbarea acesteia. Ex.:
ServerAdmin admin@aplicatii-mobile.ro
 10

d) În mod implicit, serverul web Apache, instalat odată cu pachetul WampServer,

interpretează pagina denumită index din directorul său www. În sistemul de operare Windows ,
acest director se găseste (în cazul unei instalări implicite) pe discul C. Astfel, directorul public
este “C:\wamp\www”. Putem verifica faptul ca serverul lucrează deschizând un browser web
și “apelând” http://localhost/ sau http://127.0.0.1/ (condiția este sa existe o pagină simplă
denumită index.html în directorul rădăcină descris anterior). Serverul web Apache poate, de
asemenea, face referire la o locaţie externă directorului său www, prin atribuirea unui alias.
Prin configurarea fiecărui alias se poate stabili ce locaţie pot avea utilizatorii cu drepturi de
vizualizare a paginilor web conţinute. Este necesară cunoaşterea IP- urilor sau numelor
maşinilor gazdă ale acestor utilizatori. Accesul la fiecare alias creat se face prin URL-ul de
forma…
<protocol>://<locatie server>/<nume alias>.
Dacă dorim setarea unui alias denumit “groupware” către locația d:\web\gpw, din meniul
contextual Wamp, alegem directorul Apache, Alias directories si apoi opțiunea Add an
alias. Vom specifica numele aliasului și locația sa pe disc. Serverul va intra pentru puțin timp
în starea offline pentru a scrie configurația noului alias. Conținutul fișierului de configurare
va fi de forma următoare:
Alias /groupware/ "d:/web/gpw/"
<Directory "d:/web/gpw/">
Options Indexes FollowSymLinks MultiViews
AllowOverride all
Order allow,deny
Allow from all
</Directory>

e) În demersul utilizării serverului web Apache, alte două fişiere joacă un rol deosebit:
fişierul de logare a erorilor şi fisierul de logare a accesului. Astfel, în funcţie de modalitatea
de definire a parametrilor în fişierul principal de configurare Apache, putem obţine informaţii
privitoare la erorile survenite în urma utilizării serviciului web sau în urma operaţiunilor de
configurare. Fişierul de logare a accesului ne permite vizualizarea datelor privind momentul
accesării paginilor găzduite, adresa IP a solicitantului sau a altei pagini web, ce resursă din
cadrul paginilor web a fost cerută, şi alte informaţii. Ambele pagini pot fi accesate alegând
opțiunile “Apache error log” si “Apache access log” din meniul WAMP, seciunea Apache.
Forma unei linii din log-ul de acces este urmatoarea:
IP client –[data acces] “cerere inregistrata” cod raspuns dimensiune pagina de raspuns
 11

Exemplu:
127.0.0.1--[21/Feb/2021:15:01:51+0200]"GET/webgrind/img/head.pngHTTP/1.1"200311
În ceea ce priveste erorile, câteva exemple pot fi regăsite in listing-ul următor:
[Sun Feb 21 15:01:51 2021] [error] [client 127.0.0.1] File does not exist: C:/wamp/www/favicon.ico
[Sun Feb 21 15:02:19 2021] [error] [client 127.0.0.1] PHP Stack trace:, referer:
http://localhost/webgrind/
[Sun Feb 21 15:02:19 2021] [error] [client 127.0.0.1] PHP 1. {main}()
C:\\wamp\\apps\\webgrind1.0\\index.php:0, referer: http://localhost/webgrind/

Elemente avansate de administrarea a server-ului Apache

Fiind destinat specialiștilor și nu utilizatorilor finali, așa cum am văzut în capitolul anterior,
setările serverului Apache sunt realizate modificând fișierul httpd.conf. Printre avantaje se
regăsesc cu ușurință replicării setărilor custom, dimensiunea copiilor de siguranță, chiar și
posibilitatea de fine tunning (de cele mai multe ori neregăsită într-un formular de configurare
vizuală cu elemente de UI). În acest laborator nu ne propunem să învățam despre toate
configurațiile posibile pentru serverul web. Multe dintre acestea pot fi realizate doar în situatia
unui server de producție în care putem observa diferențele date de parametrii noi introduși doar
de la un număr de accesări sau cereri de resurse în sus (de multe ori fiind vorba de access
concurențial de ordinul sutelor sau chiar miilor).
Configurarea resurselor unui oferite sau interpretate de un server web Apache este realizată
prin gestionarea de etichete (le vom denumi în continuare tag-uri, și nu doar din comoditate).
Analogia poate fi făcută în această situație cu structura unui fișier XML sau a unui fișier
HTML. Folosind Apache putem atribui tag-uri la nivel de director, fișier sau locație. Dacă
pentru fisier și director semnificațiile sunt deductibile, în ceea ce privește locațiile, Apache
consideră a fi location oricare resursă externă (de exemplu, o bază de date) și se realizează la
nivel de URL.
Revenind la tag-urile atribuite directoarelor și fișierelor, putem limita accesul la resursele
oferite de serverul web pe bază unor clase sau sub-clase de IP-uri, domenii, configurări la
nivel de comportament (răspuns contextual). Se poate realiza un set de setări implicite, care
să fie aplicate de către server tuturor directoarelor și subdirectoarelor dacă nu există alte
specificații. În exemplul următor se poate observă această configurare, așa cum este ea
definită după instalarea Apache.
<Directory />
Options FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
</Directory>
 12

Secțiunea este deschisă de tag-ul <Directory>, cu parametrul /, care desemnează

comportamentul implicit la nivelul tuturor directoarelor. Trecând peste opțiunea de utilizare a
link-urilor (legăturilor) simbolice (care este mult mai utilă celor care utilizează serverul Apache
într-un mediu Linux sau Unix, unde fișierele și directoarele sunt altfel organizate decât sub
Windows) (detalii pentru curioși), observăm directiva AllowOverride. Aceasta specifică dacă
fișierele de securitate .htaccess pot suprascrie restricțiile definite de clauza Options. În mod
implicit (și optim) este specificată valoarea None. Bunele practici Apache recomandă să păstrăm
această valoare și să o schimbăm la nivelul fiecărui director. Observăm apoi ordinea de
interpretare a clauzelor deny și allow (permisiuni și restricții) și faptul că, implicit, accesul este
interzis la nivel de directoare în setările serverului Apache.
Mergând mai departe, directorul DocumentRoot apare și el în configurația httpd implicită,
astfel:
<Directory "c:/wamp/www/">
Options Indexes FollowSymLinks
AllowOverride all
Order Deny,Allow
Deny from all
Allow from 127.0.0.1
</Directory>

Observăm o abordare pesimistă a configurației de securitate, plecând de la o interzicere a

accesului pentru toți utilizatorii și apoi adăugarea permisiunilor (în cazul nostru 127.0.0.1). O
altă abordare ar fi cea optimistă când toți utilizatorii ar putea accesa directorul menționat, în
afară de cei specificații în clauza Deny. Rămâne de văzut cum ordonăm interpretarea celor două
clauze. Astfel dacă avem ordinea Deny, Allow ar fi bine să nu includem clauza Allow from all
pentru că în felul acesta vom elimină orice setare de securitate, iar dacă avem Allow, Deny,
includerea Deny from all ne va conduce spre imposibilitatea utilizării respectivului director.
Opțiunea Indexes este strâns legată de altă directive, și anume, DirectoryIndex. Pe scurt, în
fișierul httpd.conf putem menționa care sunt fișierele considerate index pentru folder-ele
server-ului și ordinea de interpretare.
<IfModule dir_module>
DirectoryIndex index.php index.php3 index.html index.htm
</IfModule>

Dacă un anumit director nu conține unul dintre fișierele de mai sus, atunci opțiunea Indexes
intră în acțiune. Dacă este specificată, un listing al fișierele/subdirectoarelor din directorul
respectiv este oferit, altfel un frumos mesaj de Access Forbidden întâmpină utilizatorul.
Menționăm că aceleași directive se aplică și în cazul alias-urilor. După cum
 13

precizam anterior, aplicarea directivelor din tag-ul Directory este posibilă și la nivel de sub-
directoare. Dacă dorim o mai bună gestionare la nivelul acestora, putem utiliza expresii regulate
și tag-ul DirectoryMatch. În ceea ce privește gestionarea permisiunilor și setărilor la nivel de
fișier, schimbăm tag-ul <Directory> cu tag-ul <Files> (există, deasemenea un echivalent pentru
DirectoryMatch - directiva FilesMatch). Mai jos, un exemplu prin care restricționăm accesul
utilizatorilor la fișierele .htaccess și .htpasswd, făcând excepție cei care accesează aceste resurse
de pe mașina gazdă.
<Files ~ “^\.ht”>
Order deny,allow
Deny from all
Allow from from 127.0.0.1
</Files>

Virtual Hosts
Host-urile virtuale permit administratorilor de servere web Apache să administreze mai
multe site-uri utilizând aceeași mașină. Această practică se opune modalității de distribuire a
cererilor către mai multe servere web clonate (pentru a permite un nivel de scalabilitate
acceptabil) de către un load balancer (detalii pentru curioși).
Există două criterii de clasificare a host-urilor virtuale pentru Apache: în funcție de
numărul de IP-uri ale mașinii gazdă și în funcție de modul de adresare. Astfel, putem genera
hosturi virtuale pentru o mașină gazdă cu un singur IP (o singură interfață de rețea) sau
pentru o mașină gazdă care dispune de mai multe interfețe de rețea (obținând astfel și mai mule
IP-uri). Pe de altă parte, în funcție de modul de adresare, putem configura serverul web să
“asculte” cererile venite la adrese de tip IP sau la care conțin numele site-ului.
Precizări:
1) ne limităm la utilizarea unei singure interfețe de rețea
2) pentru a simula utilizarea de nume de domenii, vom edita fișierul hosts (este regăsit pe
toate mașinile gazdă care au instalat SO Windows, în folderul etc, localizat la adresa
C:\Windows\System32\drivers\etc. În Unix, /etc/hosts. Sistemul de operare Android
păstrează acest fișier în /system/etc/hosts, iar iOS în /private/etc/hosts). Acest fișier
specifică o mapare la nivelul sistemului de operare între IP-uri numele anumitor host-
uri. În mod implicit, observăm maparea realizată între localhost și 127.0.0.1. La fel de
bine putem realiza oricare altă mapare, respectând, însă, regula conform căreia o
înregistrare care începe cu același IP cu o altă înregistrare deja scrisă în fișier este una
inutilă. Doar prima dintre cele două va fi interpretată. În cazul în care dorim să
 14

utilizăm două nume de host-uri pentru a redirecta, mapa același IP, ambele vor fi trecute
pe aceeași linie. Astfel, înregistrarea corectă va fi: [IP] [Host name 1] [Host name 2]
Revenind la utilizarea de host-uri virtuale, fiecare din acestea se comportă ca un host de sine
stătător (similar celui definit în httpd.conf în mod implicit). Pentru fiecare putem utiliza toate
directivele și opțiunile recunoscute de către Apache. Aceastea pot merge de la DocumentRoot
până la ServerName, tag-uri la nivel de folder, fișier sau locație. Alături de numele sau IP ul pe
care "ascultă" host-ul virtual putem, deasemenea, specifica portul. Câteva exemple, în
următoarele linii…
<VirtualHost 192.168.1.10:80> - va gestiona toate cererile care au ca tinta ip-ul mentionat si
portul 80 (generam acelasi comportament daca nu scriam deloc numarul portului, cel implicit
fiind 80). Daca utilizam oricare alt port, acesta trebuie specificat utilizand directive Listen
<VirtualHost groupware.feaa.uaic.ro>
<VirtualHost erp.feaa.uaic.ro:88>
Exemplu
Dispunem de 3 site-uri pe care dorim să le găzduim și o singură mașină care conține o
instalare Apache. Site-urile vor avea următoarele URL: www.groupware.feaa.uaic.ro,
www.erp.feaa.uaic.ro și www.bd.feaa.uaic.ro. Întrucât sigur nu vom convinge DNS-ul că avem
aceste 3 site-uri pe mașina noastră (fără să stricăm exercițiile celorlalți din grupă), vom adăuga
linia următoare în fișierul hosts:
[IP-ulmasinii]www.groupware.feaa.uaic.rowww.erp.feaa.uaic.rowww.bd.feaa.uaic.ro

Creăm apoi un folder într-o locație pe disc pentru documentele celor 3 site-uri, (de
exemplu C:\bd\www, C:\groupware\www, C:\erp\www) și poziționăm un simplu document
index.html în fiecare dintre aceste foldere. Pentru diferențiere, vom folosi culori de fundal sau
paragrafe de text diferite.
<html><head> <title>Pagina pentru BD</title></head>
<body bgcolor=red>
<h1>Baze de date</h1>
</body></html>

Un ultim pas este să “spunem” server-ului web Apache ce trebuie să facă în cazul în care
primește o cerere pentru pagina www.bd.feaa.uaic.ro. Adăugăm următorul host virtual în
fișierul httpd.conf și efectuăm operațiunea Apache Restart All Services.
<VirtualHost www.bd.feaa.uaic.ro>
DocumentRoot "c:/host1/www"
ServerName www.bd.feaa.uaic.ro
<Directory />
Options FollowSymLinks
AllowOverride None
 15

Order deny,allow
Deny from all
</Directory>
<Directory "c:/host1/www">
Options Indexes FollowSymLinks
AllowOverride all
Order Deny,Allow
Allow from all
</Directory>
</VirtualHost>

Utilizarea .htaccess
Utilizarea fișierelor .htaccess permite administratorilor unui server web Apache să
gestioneze configurațiile de securitate la nivelul fiecărui folder. Cea mai populară utilizare (și
cea la care se face referire în acest suport) este implementarea unui mecanism de autentificare
(ce-i drept ne-securizat, întrucât parola este trimisă serverului în clar - poate fi verificată cu
Wireshark). Fișierele .htaccess pot fi poziționate la nivelul fiecărui folder, atât timp cât există
o persmisiune pentru utilizarea lor în fișierul httpd.conf. Regulile definite de aceste fișiere se
vor aplica și sub-directoarele acelui folder, dacă acestea nu au un fișier .htaccess propriu.
Dacă fișierele menționate anterior specifică un anumit comportament la nivel de folder,
ele fac apel la fișiere de tip .htpasswd pentru a extrage și verifica parola fiecărui utilizator
(dar și pentru a valida existența numelui de utilizator specificat). Acest nou tip de fișier
conține numele de utilizator și parola criptată a acestuia. Dacă .htaccess este un fișier pe care
îl putem modifica cu ajutorul oricărui editor text, .htpasswd trebuie realizat/editat cu ajutorul
unui utilitar (htpasswd.exe din distribuția Apache instalată: implicit, la adresa
C:\wamp\bin\apache\Apache2.2.22\bin\). Pentru a ajunge la acet tip de setare, se urmăresc pășii:
1) Deschidere utilitar Command line și navigare în directorul
C:\wamp\bin\apache\Apache2.2.22\bin
2) Adăugre utilizator și parola în fișierul .htpasswd (care va fi creat, în caz că nu există)
prin scrierea comenzii de mai jos și specificarea/confirmarea parolei atunci când se
solicită
htpasswd.exe –c .htpasswd user1
3) Dupa cei doi pași, consola ar trebui să arate ca în imaginea de mai jos
 16

4) Mutăm fișierul nou creat într-o altă locație, de exemplu, în folderul C:\wamp\pass
5) Vom deschide un editor de text (de exemplu Notepad++ / Notepad) și vom adauga în
noul fișier următorul conținut
AuthType Basic
AuthName AuthenticationRequired
AuthUserFile C:\wamp\pass\.htpasswd
require valid-user
6) Salvăm fișierul cu numele .htaccess (Windows nu permite redenumirea unui fișier de
acest tip (fără caracatere în fața extensiei) în Windows Explorer, în directorul care
urmează a fi securizat. În acest caz, alegem chiar DocumentRoot
7) Tot ce trebuie să facem acum este să îi precizăm server-ului Apache faptul că acest
fișier .htaccess trebuie interpretat. În primul rând ne vom asigura că următoarele module
sunt active în instalarea Apache: mod_auth_basic, mod_authn_file, mod_authz_user.
Apoi, vom edita fișierul httpd.conf pentru a modifica directiva AllowOverride din
valoarea inițială None în AuthConfig
8) Restart server Apache
9) Navigăm utilizand un browser web la pagina http://localhost
Ca rezultat al celor 9 pași urmați anterior, se va observa un formular în care trebuie să
precizăm utilizatorul și parola pentru a accesa pagina solicitată.
 17

În cazul în care refuzăm completarea sau introducem date eronate, va fi afișat un mesaj de
forma Authorization Required (eroarea 401 în Apache). Aceleași setări le putem repeta pentru
aliasuri, hosturi virtuale, sau simple foldere definite în fisierele de configurare Apache. Rămâne
doar să restricționam accesul tuturor utilizatorilor la fișierele .htaccess și .htpasswd prin
intermediul Apache. Modalitatea de realizare a acestei restricții este deja menționată în acest
support. 

Exerciții
 Realizați o nouă instalare a pachetului WAMP
 Adăugați propria pagină HTML în directorul www al serverului Apache (adăugați un
tabel, o lista, imagini, link-uri).
 Creați trei directoare, altele decât DocumentRoot și realizați diverse setări de acces
sau de afișare a indexului
 Creați două host-uri virtuale, modificând fișierul hosts din Windows (plasați convenabil
două pagini web diferite pentru vizualizare)
 Creați două alias-uri pentru două locații diferite de pe disc și restrictionati accesul
utilizatorilor prin activarea modulului de autentificare (prin fișiere de tip .htaccess)

Posibile teme pentru acasă

 Explicați cum funcționează mod_rewrite și oferiți câteva exemple (simple sau complexe)
 Realizați o instalare Apache cluster (load balancer) şi explicați avantajele acesteia