Aanbevelingen
Inleiding
In dit document geven we een aantal punten aan waarop gelet kan worden bij de eventuele verdere ontwikkeling van het GiPLan systeem. Dit zijn slechts richtlijnen en punten van aandacht. Dit document dient dus slechts als aanbeveling.
In dit document bespreken we aanbevelingen op het punt van beveiliging, het aanleggen van een schaduwdatabase en het aansturen van het systeem rechtstreeks in PHP.
Beveiliging
Het is raadzaam om de door GiPLAN gemaakte interface te beveiligen. Dit voorkomt dat gebruikers die daar niet toe bevoegd zijn aanpassingen kunnen maken in het systeem. Hoe meer de interface uitgebreid zal worden, hoe groter het belang van beveiling zal worden. In dit document doen wij een paar suggesties over hoe dit op te lossen is. Deze aanpassingen zullen niet door de eindgebruikers kunnen worden gedaan, maar zullen moeten worden geimplementeerd door (bv) schoolLAN.
Manieren van beveiligen
Er zijn verschillende manier om de interface af te schermen. De één is veiliger dan de ander, maar elke manier heeft zijn eigen moeilijkheden bij de implementatie ervan.
-
'Geheime' directorie
Het is mogelijk om het GiPLAN-systeem te installeren in een 'geheime' directorie. Dat wil zeggen, in een directorie die niet bekend is voor ongeauthoriseerde gebruikers. Deze manier is erg makkelijk te realiseren. Echter, hij is absoluut niet veilig. Een gebruiker hoeft maar één keer de directorie te vinden en de beveiliging is eigenlijk opgeheven. Deze methode wordt dan ook afgeraden.
-
.htacces- bestanden
Wanneer iemand gebruikt maakt van een Apache webserver, zoals bij schoolLAN, is het meestal mogelijk om ook gebruik te maken van .htaccess bestanden, Access Control wordt dit genoemd. Access Control heeft ontzettend veel mogelijkheden, maar we zullen het hier niet te uitgebreid behandelen.
Configuratie van Apache
Als eerste moet in het Apache configuratie bestand .htaccess geactiveerd staan en de naam moet op .htaccess staan. Dit staat in het httpd.conf bestand, dit bestand staat in de conf directory van de Apache server. Allereerst zet je de naam van het Access bestand op .htacces, dit is de "AccessFileName" optie in httpd.conf. Standaard staat dit al op .htaccess dus hier zou je al niets aan hoeven te passen.
Vervolgens moet de "AllowOverride" optie in httpd.conf aanstaan, dus niet op "None", wat het wel standaard staat. AllowOverride zorgt ervoor dat je de .htaccess file kunt gebruiken. Voor uitgebreide documentatie verwijzen wij u naar de handleiding van Apache.
Beveiliging van een directory
Wanneer je in een bepaalde directory een .htaccess bestand zet, kun je deze directory beveiligen met een username en wachtwoord. Wanneer je het volgende in je .htaccess zet, zal je een window krijgen die om username en wachtwoord vraagt wanneer je de directory aanroept:
AuthUserFile /path/to/htpasswd/file/.htpasswd
AuthGroupFile /dev/null
AuthType Basic
AuthName "Password protected Area"
<limit GET>
require valid-user
</limit>
Een korte uitleg over deze file:
AuthUserFile /path/to/htpasswd/file/.htpasswd
Dit is de directory waar je .htpasswd file staat, het bestand waar je de usernames en wachtwoorden in opslaat.
AuthGroupFile /dev/null
Dit is de directory naar je "Group File". In je group file, staan de groepen en users die bij een bepaalde groep horen. In dit geval gebruik ik /dev/null, dit betekent dat ik geen group file heb. /dev/null is eigenlijk een UNIX pad (naar niets).
AuthName "Password protected Area"
De naam die je te zien krijgt in het window als je de directory aanroept. Wanneer dit dus meer dan 1 woord is, moet je het tussen aanhalingstekens zetten.
<limit GET> ... </limit>
Hiermee limiteer je de methode van opvragen van een pagina. HTTP requests worden gemaakt via GET of POST, dit is de methode van opvragen. Dus hier mag je alleen gebruik maken van de GET methode. Let wel op dat alles wat je hierin zet, case-sensitive is.
De volgende methoden zijn beschikbaar: GET, POST, DELETE, PUT, COPY, MKCOL, MOVE, LOCK, UNLOCK, TRACE, CONNECT, OPTIONS, PATCH, PROPPATCH en PROPFIND. Gebruik bij deze limit altijd GET.
require valid-user
Hiermee zorg je ervoor dat elke user die in je .htpasswd file staat in kan loggen. Je kunt hier gebruik maken van de volgende opties:
- require user naam1 naam2 naam3
- require group groep1 groep2
- require valid-user
Nu is er een .htacces bestand die de directorie beveiligt. Om in te kunnen loggen hebben we ook nog een file nodig waarin de wachtwoorden staan (standaard heet die file .htpasswd). Het programmaatje waarmee je wachtwoorden aanmaakt, zit ook bij Apache. Dat staat in de "bin" directory en heet "htpasswd".
Wanneer je voor het eerst een wachtwoord toevoegt, moet je de -c optie gebruiken om het wachtwoord bestand aan te maken. Dus aan de hand van het voorbeeld .htaccess bestand doe je:
htpasswd -c /path/to/htpasswd/file/.htpasswd username
Dus je gebruikt hier het pad (en wachtwoord bestand) wat je in AuthUserFile hebt gebruikt. Als je dit runt, moet je nog 2 keer een wachtwoord invoeren. Hierna kun je je beveiligde directory aanroepen en testen.
Als je nu een user wilt toevoegen aan je bestaande wachtwoord type je
htpasswd -c /path/to/htpasswd/file/.htpasswd username password
-
PhP-sessions
Sessions zijn de manier van PHP om gegevens te koppelen aan een bezoeker van de website.
Hoe werken PHP-sessions?
Het HTTP protocol is een protocol welke geen verbinding in stand houdt met de bezoeker. Om dan toch gegevens aan een bezoeker te kunnen koppelen zijn er een aantal opties bedacht. De meeste bekende en beruchte is die van cookies (kleine tekstbestandjes die op de pc van de bezoekr worden geplaatst). De webserver vraagt aan de browser om bepaalde gegevens op te slaan, gekoppeld aan het domein van de server. Bij iedere connectie met de server kan deze aan de browser om de gegevens vragen welke zijn opgeslagen in de cookie. Een nadeel van deze methode is dat er mogelijk veel informatie uitgewisseld gaat worden zodra de bezoeker veel pagina's op de server gaat bekijken en doordat de informatie aan de kant van de bezoeker wordt opgeslagen is het mogelijk dat er met de informatie is geknoeid.
Een andere mogelijkheid is om bezoekers, zodra ze binnenkomen een uniek nummer (session id) op de server te geven. Dit nummer wordt dan aan iedere URL geplakt en zo wordt de gebruiker gevolgd over de website. Nadeel hiervan is dat bij simpele nummers bezoekers het nummer van een andere website bezoeker kunnen raden en zo dus eventuele gevoelige informatie van een andere klant bekijken.
PHP gebruikt het beste van de twee werelden. Het maakt voor iedere bezoeker een uniek nummer en probeert deze in een cookie bij de gebruiker op te slaan. De cookie vervalt zodra de bezoeker de site (browser) sluit of met de standaard instellingen van PHP als de site 20 minuten niet actief is bezocht door de bezoeker.
Heeft de bezoeker cookies uitstaan, dan gaat PHP de URLs aanpassen door de session id eraanvast te plakken. Een PHP session id bestaat standaard uit een 128 bits getal en het is dus zeer onwaarschijnlijk dat de bezoeker de session id van een andere bezoeker zal raden. (maar niet onmogelijk).
Hoe kunnen we dit toepassen voor schoolLAN?
In de PHP session kunnen we ook andere variabelen bewaren. Voor ons geval is het handig als we het als volgt doen: bij het opvragen van elke pagina kijken we of er voor de gebruiker al een session actief is. Zo nee, dan laten we hem inloggen. De opgegeven gebruikersnaam en wachtwoord kunnen we dan opslaan in een PHP session. We zullen echter ergens moeten controleren of de gebruikersnaam en het wachtwoord bij elkaar horen. Daarvoor kunnen we twee dingen doen:
- Een tekstbestandje op de server zetten, waarin we de gebruikersnamen en bijbehorende wachtwoorden opslaan.
- Nog mooier is om gebruikersnamen en wachtwoorden op te slaan in een database. Voordeel ten opzichte van bovengenoemde optie is dat het makkelijker is om de gegevens terug te halen.
Bij het inloggen controleren we dus of de combinatie van gebruikersnaam en wachtwoord bestaan. Zo niet, dan heeft de gebruiker klaarblijkelijk geen toegang tot het opgevraagde document. Zo ja, dan kunnen we de pagina gewoon laten zien. Omdat we de gegevens registreren in een session, hoeft de gebruiker niet steeds opnieuw in te loggen. Deze manier van opslaan zorgt er ook voor dat niet alle gebruikers hoeven te worden geregistreerd. Alleen degene die toegang hebben tot het GiPLAN-systeem hoeven hierin te staan.
Uitbreidingen
Dit systeem is natuurlijk zover uit te breiden als je wilt. Een mooie uitbreiding zou zijn om bij elke gebruiker ook op te slaan tot welke opties van het GiPLANsysteem hij toegang heeft. Op die manier kan per de toegang tot in de details geregeld worden.
Schaduw database
Er kan worden overwogen om een schaduwdatabase aan te maken waarin de systeem-gegevens worden bijgehouden. Hierbij denken we aan een database die eenvoudig aangesproken kan worden vanuit PHP (bijvoorbeeld MySQL of PostgreSQL). In deze database kunnen dan vervolgens de gebruikers-gegevens van alle gebruikers worden opgeslagen.
Voordelen
Doordat de gegevens in een database zijn opgeslagen zijn deze eenvoudig te benaderen vanuit de PHP-scripts. Nu staan de gegevens nogal onduidelijk opgeslagen in systeembestanden en wordt aan de hand van de directory structuur bepaald of een bepaalde gebruiker bestaat. Wanneer er nu echter iets veranderd in de structuur van het schoolLAN systeem werken de scripts waarschijnlijk niet meer. Door het gebruik van een schaduw-database wordt dit voorkomen.
De gegevens uit de database kunnen ook worden gebruikt om een beveiliging met PHP, zoals in het vorige hoofdstuk aangegeven, te realiseren aangezien gegevens zoals gebruikersnaam en wachtwoord dan reeds bekend zijn binnen de PHP-scripts, terwijl de wachtwoorden van de gebruiker momenteel niet eenvoudig te achterhalen zijn.
Nadelen
Een groot nadeel is dat er voor gezorgd moet worden dat de toestand van het systeem en de schaduwdatabase met elkaar overeenkomen. Bij elke aanpassing moet er dus voor worden gezorgd dat zowel het schoolLAN systeem als de schaduwdatabase worden bijgewerkt.
Als er iets fout gaat met de database of het systeem moet er voor gezorgd worden dat beide systemen weer een zelfde toestand representeren. Om dit te realiseren zal er een script gemaakt moet worden dat de database weer invuld aan de hand van het systeem en vice versa.
Verder zorgt de database voor een extra overhead. Er moet een database-server worden geinstalleerd en deze moet worden onderhouden en dit vereist de nodige expertise. De kennis hiervoor is echter ruimschoots te vinden via het Internet en in dit specifieke geval zal er waarschijnlijk niet al te veel specialistische kennis noodzakelijk zijn.
Systeembeheer in PHP
Het systeem wordt momenteel beheerd met een verzameling scripts geschreven in Perl. Aangezien het GiPLan systeem in PHP is gemaakt scheelt het een extra interface laag wanneer de scripts om het systeem te beheren ook in PHP gemaakt zouden worden. Op deze manier kunnen er veel directere en gebruiksvriendelijkere foutmeldingen aan de gebruiker worden gegeven.
Verder is de functionaliteit van PHP vrijwel gelijk aan Perl en zijn zeker de scripts die nu aanwezig zijn om te zetten naar PHP. In PHP is de eventuele schaduwdatabase ook zeer eenvoudig aan te spreken.
Tevens wordt het aantal aanwezige programmeertalen beperkt en dit is altijd een goede zaak aangezien dit betekent dat het beheer eenvoudiger wordt.
Het is altijd een goede zaak om zo weinig veranderlijke elementen hard te coderen in de code. Wanneer er nu eventueel voor gekozen wordt om het systeem te herschrijven in PHP kan het zinvol zijn om alle variabelen die eventueel zullen veranderen, zoals directory namen etc. centraal ergens op te slaan zodat ze op een plaats gewijzigd kunnen worden.
Werken vanuit gebruikers-perspectief
Bij het maken van een gebruikers-interface moet er natuurlijk gewerkt worden vanuit het standpunt van de gebruiker aangezien deze gebruik zal gaan maken van de interface. Maar ook bij de ontwikkeling van het systeem is het van belang om de wensen van de gebruikers in de gaten te houden.
Men kan wel een geweldige optie in het systeem inbouwen, maar wanneer de gebruiker deze vervolgens niet gaat gebruiken is dit verspilde energie geweest.
Conclusie
Het GiPLan systeem is in grote mate bovenop het huidige systeem gebouwd, terwijl er met een aantal aanpassingen voor gezorgd kan worden dat de gebruikersinterface veel makkelijker te implementeren is. Op deze manier wordt het een onderdeel van het eigenlijke schoolLAN systeem waardoor aanpassingen makkelijker door te voeren zijn en de totale ontwikkelingstijd hoogst waarschijnlijk zal afnemen.
|