Ontwerp en implementatie van hulpmiddelen voor geautomatiseerde verwerking van ingezonden broncode Johan Beke, Leen Vancoillie
Promotoren: prof. dr. ir. Bart Dhoedt, prof. dr. ir. Filip De Turck Begeleider: Olivier Van Laere Masterproef ingediend tot het behalen van de academische graad van Master in de toegepaste informatica
Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Faculteit Ingenieurswetenschappen en Architectuur Academiejaar 2010-2011
Ontwerp en implementatie van hulpmiddelen voor geautomatiseerde verwerking van ingezonden broncode Johan Beke, Leen Vancoillie
Promotoren: prof. dr. ir. Bart Dhoedt, prof. dr. ir. Filip De Turck Begeleider: Olivier Van Laere Masterproef ingediend tot het behalen van de academische graad van Master in de toegepaste informatica
Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Faculteit Ingenieurswetenschappen en Architectuur Academiejaar 2010-2011
Inhoudsopgave Voorwoord 1 Inleiding
1
1.1 Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2 Probleemanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.3 Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2 Architectuur
4
2.1 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2 Architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3 Implementatie
6
3.1 Algemene opbouw webplatform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Mappenstructuur
6
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3.1.2 Opbouw pagina’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.2 Ontwerp database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.2.1 Analyse van de vereisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.2.2 EER-model database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.2.3 Omzetting naar tabellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.3 Ontwerp login systeem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.4 Ontwerp willekeurige wachtwoord generator . . . . . . . . . . . . . . . . . . . . . . .
15
3.5 Ontwerp pdf ondersteuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.5.1 Overerving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.5.2 Syntaxiskleuring voor broncode
. . . . . . . . . . . . . . . . . . . . . . . . .
16
3.5.3 Pagina toevoegen aan een pdf-bestand . . . . . . . . . . . . . . . . . . . . .
17
3.5.4 Samenvoegen van pdf-bestanden . . . . . . . . . . . . . . . . . . . . . . . .
17
3.5.5 Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.6 Ontwerp klasse Exam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.7 Ontwerp beheerders gedeelte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.7.1 Toevoegen en aanpassen van een examen . . . . . . . . . . . . . . . . . . .
20
3.7.2 Uploaden en downloaden van een studentenlijst . . . . . . . . . . . . . . . .
21
3.7.3 Overzicht studenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.8 Aanpassen configuratie variabelen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.9 Ontwerp studenten gedeelte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.9.1 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.9.2 Overzicht examen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4 Demo
26
4.1 Assistent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.2 Student
30
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Toekomstig werk en besluit
32
5.1 Toekomstig werk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
5.1.1 Examenbegeleiders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
5.1.2 Foutafhandeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
5.1.3 Unit testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
5.1.4 Aanpassen configuratievariabelen . . . . . . . . . . . . . . . . . . . . . . . .
33
5.2 Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
A Database SQL-query
35
B Installatie
37
B.1 Mappen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
B.2 Installatie procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
B.3 Vereisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
C Cd-rom
39
Referenties
40
Lijst van figuren
41
Lijst van broncode
42
Voorwoord Deze masterproef werd gerealiseerd voor het behalen van de graad Master na Master in de Toegepaste Informatica. Zonder de hulp van sommige mensen zou dit niet mogelijk zijn geweest. In de eerste plaats willen wij onze promotoren Prof. Dr. ir. Bart Dhoedt en Prof. dr. ir. Filip De Turck bedanken voor het uitschrijven en promoten van het onderwerp van deze masterproef. Daarnaast willen wij ir. Olivier Van Laere bedanken voor zijn steun, begeleiding en nuttige tips. Ten slotte willen wij ook onze ouders bedanken voor de steun en de kansen die zij ons hebben geboden.
De toelating tot bruikleen "De auteurs geven de toelating deze masterproef voor consultatie beschikbaar te stellen en delen van de masterproef te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze masterproef." "The authors give permission to make this master dissertation available for consultation and to copy parts of this master dissertation for personal use. In the case of any other use, the limitations of the copyright have to be respected, in particular with regard to the obligation to state expressly the source when quoting results from this master dissertation."
24 mei 2011
INLEIDING
1
Hoofdstuk 1
Inleiding 1.1
Probleemstelling
Een aantal examens aan de faculteit ingenieurswetenschappen en architectuur, zoals bijvoorbeeld het examen informatica voor de eerste bachelor, vereisen het indienen van broncode bestanden. Tot nu toe werden deze bestanden opgehaald met een USB-stick. Om verscheidene redenen loopt dit af en toe fout. Het kan gebeuren dat niet alle vereiste bestanden worden ingediend of dat de inhoud niet voldoet aan de vereisten, met alle gevolgen van dien. Tevens geeft een kopij op een USB-stick geen feedback indien er fouten zijn ontstaan bij het kopiëren van de broncode. In deze masterproef wordt een toepassing ontwikkeld die deze problemen kan vermijden en de student meer zekerheid kan geven dat zijn examen op een correcte manier is ingediend.
1.2
Probleemanalyse
Studenten hebben tijdens een examen dat ze niet schriftelijk kunnen indienen enerzijds weinig zekerheid dat hun opgelost examen volledig en correct wordt ingediend. Anderzijds worden veel richtlijnen op een examen over het hoofd gezien, door de stress van het moment, of doordat deze richtlijnen verkeerd worden geïnterpreteerd. Hierdoor ’verdwijnen’ soms examens, of delen van examens, van bepaalde studenten. Het verdwijnen kan een technische oorsprong hebben en voortkomen uit het feit dat de bestanden niet correct werden overgebracht naar de USB-stick. Wanneer de USB-stick bijvoorbeeld niet veilig wordt verwijderd en het proces van overzetten van de bestanden nog niet was beëindigd, zijn de bestanden op de USB-stick onleesbaar. De student is echter in de waan dat hij zijn examen correct heeft ingediend, terwijl de assistent bij verbetering enkel onleesbare bestanden terugvindt. Na het
1.3 Samenvatting
2
indienen van de examens worden basiscontroles uitgevoerd, maar deze geven enkel aan of er bestanden werden ingediend en niet of deze bestanden ook leesbaar zijn. Een ander punt waarop het gehele proces kan fout lopen zijn de bestandsindelingen die bruikbaar zijn voor de assistent. Hoewel op het examen wordt vermeld dat enkel de extensies .java en .m worden aanvaard, worden door de studenten vaak bestanden in andere bestandsindelingen ingediend. Vaak .class bestanden, waar zelfs eventueel de extensie manueel naar .java werd veranderd. Ook andere bestandsindelingen zoals tekstbestanden en MS Word-bestanden worden soms ingediend. Het valt bovendien ook moeilijk te controleren of een student een vraag al dan niet blanco heeft ingediend. Op een blad papier is dit duidelijk te zien, maar als een verwacht bestand niet wordt gevonden op de USB-stick, kan dit ook één van de bovenstaande oorzaken hebben. Dit vormt een soort van achterpoortje in het systeem. De student zou achteraf kunnen beweren dat hij wel degelijk iets heeft ingediend, maar dat dit op de een of andere manier verloren is gegaan. Verder is het voor de student moeilijk om een overzicht te krijgen van het examen dat hij gaat indienen, omdat dit examen bestaat uit allemaal aparte bestanden. Hij kan ook moeilijk verifiëren dat al deze bestanden uiteindelijk inderdaad op de USB-stick terechtkomen. Op een examen moet op het einde alles vaak ook snel gebeuren, wat er natuurlijk voor zorgt dat dingen nog makkelijker verkeerd kunnen lopen. Bij een uitgebreide analyse van het probleem en zijn deelproblemen werd het use case diagram opgesteld zoals te zien in figuur 1.1.
1.3
Samenvatting
Om examens waarbij broncode bestanden moeten worden ingediend in goede banen te leiden, heeft de student nood aan een systeem waarbij hij zelf verantwoordelijk is voor het correct afleveren van de bestanden die hij wil indienen. Tevens is er nood aan een duidelijk overzicht van het gehele examen zoals het zal worden ingediend. De begeleider heeft nood aan een systeem waarbij hij zeker is dat de student elke stap die hij neemt, heeft bevestigd en waarbij er enige controle wordt ingebouwd op de bestanden die kunnen worden ingediend.
Figuur 1.1: Use case diagram webplatform
Submit exam
View problem status
Preview exam Pdf
View uploaded files
Upload file
Student
Unsubmit exam
Log out
Log in
(Assistant)
Administrator
List exams
Edit config file
Add exam
uses
Delete student
uses
View files uploaded by student
Manage exams
uses uses
Delete file
extends
Edit exam
Upload student list
Delete problem
Add problem
Delete rule
Add rule
Delete exam
Change student password
Download exam Pdf
Create exam Pdf
List students registered for an exam
Download student list
View exam
1.3 Samenvatting 3
ARCHITECTUUR
4
Hoofdstuk 2
Architectuur 2.1
Analyse
De toepassing die werd ontwikkeld, moest in de eerste plaats toelaten dat een student een examen correct kan indienen en in de tweede plaats dat een assistent dit examen kan bekijken. De examens worden afgelegd in groepen van om en bij de twintig studenten in verschillende pc-klassen. Aangezien er heel wat studenten zijn, en er slechts vijf klassen tegelijk beschikbaar zijn, moeten de studenten opgedeeld worden in verschillende reeksen. Concreet betekent dit dat er per examen vier reeksen examens na elkaar worden gegeven. Dit gebeurt telkens in vijf verschillende klassen van ongeveer twintig studenten. Hiervoor zijn in realiteit twintig mensen met verschillende USB-sticks om dit te beheren. Er werd beslist dat het gebruik van USB-sticks om de examens op te halen in elk geval vermeden moest worden. Verder was het ook niet mogelijk om op de pc’s in de klassen programma’s te gaan installeren. Een webgebaseerde toepassing leek dus de beste optie, omdat deze van op gelijk welke plaats te bereiken valt en geen installatie vereist. Een mogelijk probleem hierbij is dat de studenten toegang tot het Internet moeten hebben en dus ook allerlei andere pagina’s zouden kunnen bereiken. In dit geval zou er natuurlijk strenge controle van de assistenten nodig zijn. Het gebruik van het Internet kan in elk geval niet vermeden worden, maar het zou bijvoorbeeld wel mogelijk zijn om de studenten slechts gedurende een bepaalde tijd toegang te geven tot het Internet, zodat controle gemakkelijker wordt. De webinterface zou uit twee delen moeten bestaan. Een deel voor de assistenten waar zij (minimaal) examens kunnen aanmaken, studenten kunnen toevoegen en examens kunnen raadplegen. Daarnaast het deel voor de studenten waar zij hun bestanden kunnen uploaden naar de server en hun examen kunnen bekijken. De studenten mogen uiteraard geen toegang hebben tot het deel
5
2.2 Architectuur van de assistenten.
Er werd gekozen om de examens op de server op te slaan enerzijds als de aparte bestanden die door de student worden geüpload, anderzijds onder de vorm van een pdf-document.
Dit
pdf-document zou dan een opeenvolging zijn van de bestanden die per vraag door de student worden geüpload. Op die manier kan de student een volledig overzicht van zijn examen bekijken.
2.2
Architectuur
Voor het webplatform moet er in elk geval een interface worden gemaakt en is een database nodig. De database is nodig om gebruikers en hun wachtwoorden te kunnen opslaan en de verschillende examens en hun structuur te kunnen bijhouden. Er werd geopteerd om als database MySQL te gebruiken. De keuze hiervoor is gebaseerd op het feit dat dit een open source systeem is en SQL de de facto standaard is voor de bevraging van databases [1]. Voor de server-side programmeertaal van de webinterface waren er verschillende mogelijkheden; waaronder ASP.NET, PHP, Python, Ruby, e.a. Aangezien ASP.NET commerciële software vereist en enkel draait op een windows-compatibele architectuur, werd hiervoor niet gekozen. Python en Ruby zijn ongeveer analoge programmeertalen, maar gelijken minder op java in vergelijking met PHP. Tevens is PHP wijder verspreid en bestaat het langer dan Python en Ruby als webplatform. Omdat PHP volledig vrij beschikbaar en platformonafhankelijk is, werd dit de eerste keuze voor het gebruik in deze masterproef. Voor het genereren van pdf bestanden zijn er verschillende bibliotheken beschikbaar. De belangrijkste zijn PDFlib1 , FPDF2 , TCPDF3 en ClibPDF4 . De laatstgenoemde bibliotheek zou een pdf volledig in het geheugen opbouwen maar vereist het hercompileren van PHP [3]. Aangezien de bibliotheek geen recente releases heeft, was het evenwel niet aan te raden deze te gebruiken. PDFlib is de standaard bibliotheek opgebouwd als PHP extensie voor PDFlib GmbH [4]. Aangezien deze bibliotheek niet open source is [3] genieten andere bibliotheken de voorkeur. Twee andere interessante bibliotheken zijn FPDF en TCPDF. Beide hebben voor- en tegenstanders maar aangezien FPDF zeer eenvoudig is uit te breiden [5] en geen extra bibliotheken nodig heeft [4], genoot deze de absolute voorkeur.
1
http://www.pdflib.com/ http://www.fpdf.org/ 3 http://www.tcpdf.org/ 4 http://www.fastio.com/ 2
IMPLEMENTATIE
6
Hoofdstuk 3
Implementatie Dit hoofdstuk omvat een beschrijving van de implementatie van de belangrijkste functionaliteit. Om de leesbaarheid te bevorderen, wordt niet telkens de volledige broncode weergegeven, maar enkel een gedeelte ter verduidelijking waar nodig. De volledige broncode wordt meegeleverd als bijlage op een cd-rom (Bijlage C).
3.1 3.1.1
Algemene opbouw webplatform Mappenstructuur
Het globale webplatform is opgebouwd uit drie mappen. De map web is de document root en dus de enige map die publiekelijk toegankelijk mag zijn. De twee andere mappen, upload en code, worden om veiligheidsredenen buiten de document root geplaatst [2]. Op die manier is het niet mogelijk dat een student de geüploade bestanden van een andere student kan bekijken door het raden van de url. Om dit nog extra te beveiligen is het aan te raden het indexeren van mappen op de server niet toe te staan.
7
3.1 Algemene opbouw webplatform
De map web bevat de pagina’s index.php en admin.php, die, indien nodig, alle andere pagina’s en klassen aanroepen met behulp van de include functie. Deze map bevat ook de mappen die de Javascript bestanden, CSS-bestanden en afbeeldingen bevatten. (figuur 3.1) De map code bevat de pagina’s en klassen die worden opgevraagd vanuit de PHP code in de document root. Deze map bevat eveneens de extra bibliotheken. (figuur 3.2)
web css images
.js
js
.js
.php
admin.php
.js
.php
index.php
.php
includeall.php
.php
....
exam.js popup.js submitform.js
Figuur 3.1: Mappenstructuur van de documentroot (web)
.php
code
.php
pages
.php
FPDI-1.4.1
.php
addexam.php .... upload.php
fpdf
.php
classes
.php
global_vars.php
.php
Dir.php .... RandomPassword.php
Figuur 3.2: Mappenstructuur van de code map
8
3.1 Algemene opbouw webplatform
De map upload bevat alle bestanden die worden geüpload door de studenten. De bestanden van de studenten worden per examen, per groep, per pc klas en per student geklasseerd. Binnen de map van de student wordt er per vraag van het examen een map aangemaakt die de geüploade bestanden zal bevatten. De map van de student krijgt zijn studentennummer als naam, de mappen voor de verschillende vragen worden benoemd als Problem met daarna het volgnummer van de vraag. Na het indienen of het aanmaken van het pdf-bestand voor de verbetering zal deze map dat bestand bevatten. Het volledige pdf-bestand met de ingediende code van alle studenten wordt opgeslagen in de map van het betreffende examen. (figuur 3.3) De paden naar de map upload en de map code worden gespecificeerd in het bestand config.php zodat deze mappen eender waar kunnen worden geplaatst. Elke verwijzing naar deze mappen zal dan door een $config[naam] variabele vooraf moeten worden gegaan. 1
upload Hypothetisch_examen
2
PC-A
....
....
PC-B ....
.pdf
Hypothetisch_examen.pdf
20054901
problem_1
.java
oplossing.java
01000058
problem_2
.java
....
.... .... .pdf
20054901.pdf
Figuur 3.3: Mappenstructuur van de upload map
3.1 Algemene opbouw webplatform
3.1.2
9
Opbouw pagina’s
De basis van het webplatform bestaat uit twee hoofddocumenten, index.php en admin.php, opgebouwd zoals weergegeven in broncode 3.1. Elke HTML pagina bevat een hoofding, een voettekst en de nodige verwijzingen naar CSS en Javascript bestanden. Deze basis HTML uitvoer wordt op elke pagina geplaatst met de methoden html_head en html_foot, zodat op elke pagina de lay-out analoog is [9]. In admin.php worden de verschillende pagina’s gespecificeerd met een naam in de url. De url /admin.php?page=addexam zal dan bijvoorbeeld verwijzen naar de pagina waarop een nieuw examen kan worden aangemaakt. Op basis van $_GET["page"] wordt dan deze pagina met de include functie ingevoegd in de hoofdpagina admin.php. Broncode 3.1: Basisconcept admin.php 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
i s l o g g e d i n ( ) && ( $auth −>isAdmin ( ) | | $auth −> i s A s s i s t a n t ( ) ) ) { ?> ... Welcome .
Login < / a>
3.2 Ontwerp database 33 34 35 36 37
10
} ob_end_flush ( ) ; html_foot ( ) ; $mysqli −>c l o s e ( ) ; ?>
Het bestand index.php bevat bijna de volledige functionaliteit voor de studenten. Andere functionaliteit, zoals het indienen van het examen, wordt op een extra pagina gerealiseerd waarna een redirect wordt uitgevoerd naar de index pagina. De pagina admin.php is bewust in meer onderdelen opgesplitst, aangezien deze uit veel meer code bestaat. Om alle functionaliteit eenvoudig te kunnen gebruiken en te kunnen onderhouden volstaat het toevoegen van includeall.php. Deze pagina bevat alle includes in een welbepaalde volgorde, die vereist is voor de overerving tussen de verschillende klassen.
3.2 3.2.1
Ontwerp database Analyse van de vereisten
Voordat de tabellen van de database en hun onderlinge relaties gekend zijn, moet de database ontworpen worden. Zoals reeds vermeld in de doelstellingen moeten er examens kunnen worden opgeslagen. Elk examen bevat een aantal vragen en elk van die vragen kan dan weer een aantal inhoudsregels bevatten waar de bestanden die door de studenten werden geüpload, aan moeten voldoen. Een examen heeft een naam en een datum. Elk probleem is gekoppeld aan een examen en heeft een beschrijving en een naam. Elke regel is gekoppeld aan een probleem en heeft een type, een zoekstring en een foutboodschap. Uiteraard moeten de gebruikers ook worden bijgehouden. Een gebruiker wordt gekenmerkt door zijn studentennummer, voornaam, achternaam, wachtwoord en rol (student, begeleider, enz.). De gebruikers, indien het studenten zijn, worden gelinkt aan het door hen af te leggen examen. Voor elke student die wordt toegevoegd, moeten de volgende zaken worden bijgehouden: zijn groepsnummer, de reeks van het examen waar hij aan deelneemt, het auditorium waar hij het examen aflegt, en een variabele die aanduidt of hij zijn examen heeft ingediend.
11
3.2 Ontwerp database
3.2.2
EER-model database
Bovenstaande analyse kan worden omgezet in een zogenaamd enhanced entity-relationship-model (EER-model) waaruit de nodige tabellen kunnen worden afgeleid [1]. Voor deze database vertaalt zich dat in het EER-model zoals weergegeven in figuur 3.4. De entiteiten problem en contentrule zijn zwak aangezien er geen vraag kan bestaan zonder bijhorend examen en geen regel zonder een bijhorende vraag. Zodoende is de participatie van deze entiteiten dan ook totaal. De participatie van de entiteit user wordt ook als totaal verondersteld aangezien studenten altijd aan een examen moeten deelnemen. Het zou anders niet nuttig zijn om deze student in het systeem op te nemen. Elke student kan slechts ingeschreven zijn voor één examen maar een examen kan uiteraard meerdere studenten bevatten. Dit wordt voorzien in het diagram met een één-op-meerdere relatietype (1:N). Analoog wordt dit voorzien voor de vragen en de regels die bij de vragen horen. submitted
group
nr
auditorium date exam name
1
participates
name lastname
user
N
password role
1 searchstring has
N
name
problem
1
has
N
contentrule
type
errormessage description
Figuur 3.4: EER-model database
3.2.3
Omzetting naar tabellen
Vanuit het EER-model kunnen nu de verschillende tabellen en attributen worden afgeleid. Tevens worden de verschillende relaties verwerkt in de tabellen of met een extra tabel. De volgende tabellen werden gedistilleerd uit het opgestelde model: users, exams, problems, contentrules en registration. Elke tabel krijgt een id dat gebruikt wordt om de relaties te leggen tussen de tabellen onderling. De tabel problem heeft bijvoorbeeld een attribuut examid om de vragen te koppelen aan hun overeenkomstig examen.
12
3.2 Ontwerp database
De relatie tussen studenten en hun examen wordt gelegd met een extra tabel, namelijk registration, die dan ook meteen de groep, het auditorium en een variabele die bepaalt of het examen is ingediend, zal bevatten. Een globaal beeld van de tabellen wordt in figuur 3.5 gegeven. De links worden verwezenlijkt in MySQL waarbij het on delete kenmerk cascade wordt gekozen. Zodoende zal bij het verwijderen van een student automatisch het overeenkomstige record verdwijnen in de tabel registration. Analoog zullen bij verwijdering van een examen de onderliggende vragen en regels ook mee worden verwijderd.
Blad1
contentrules Veld id problemid type searchstring errormessage
Type int(11) int(11) tinytext longtext text
Null Gelinkt naar Nee Nee problems→id Nee Nee Nee
exams Veld id date name
Type int(11) date text
Null Gelinkt naar Nee Nee Nee
problems Veld id examid name description
Type int(11) int(11) text text
Null Gelinkt naar Nee Nee exams→id Nee Nee
registration Veld id nr examid groupid auditorium submitted
Type int(11) int(11) int(11) int(11) text tinyint(4)
Null Gelinkt naar Nee Nee users→nr Nee Nee Nee Nee
users Veld id name lastname nr password role
Type int(11) text text int(11) text text
Null Gelinkt naar Nee Nee Nee Nee Nee Nee
Figuur 3.5: Tabellen in de database Het geheel aan tabellen en relaties kan met een SQL-query aan de MySQL database worden toegevoegd. De volledige query staat beschreven in appendix A.
13
3.3 Ontwerp login systeem
3.3
Ontwerp login systeem
Authenticatie kan op verschillende manieren. De voornaamste methoden gebruiken PHP sessievariabelen of het HTTP authenticatie systeem. Het HTTP authenticatie systeem is eenvoudig in gebruik, maar heeft enkele nadelen: de webbrowser zal de gegevens opslaan (wat een veiligheidslek kan zijn) en het systeem kan niet geïntegreerd worden in de lay-out van de bestaande pagina’s [10]. Zodoende is het beter en algemeen gangbaar om authenticatie te baseren op sessievariabelen. De klasse Login omvat alle methoden om het inloggen af te handelen. Bij een succesvolle aanmelding worden de sessievariabelen opgeslagen zoals weergegeven in tabel 3.1. Broncode 3.2 geeft de methode weer die bij de aanmeldingsprocedure wordt aangeroepen. Broncode 3.2: Methode login 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
p u b l i c s t a t i c f u n c t i o n l o g i n ( $user , $pass , $ m y s q l i _ o b j e c t ) { $query = "SELECT password , name , lastname , r o l e FROM users WHERE n r = ? " ; $stmt = $ m y s q l i _ o b j e c t −>prepare ( $query ) ; $stmt −>bind_param ( " s " , $ v a l 1 ) ; / / avoid sql i n j e c t i o n i f ( ! i s _ n u m e r i c ( $user ) ) { / / user has n o t t h e expected f o r m a t throw new Ex c e p t i o n ( ’ Could n o t l o g i n . Please check your i n p u t ! ’ ) ; } $ v a l 1 =$user ; $stmt −>execute ( ) ; $stmt −>b i n d _ r e s u l t ( $password , $name , $lastname , $ r o l e ) ; i f ( $stmt −>f e t c h ( ) ) { / / p o s s i b l e user , check f o r password i f ( sha1 ( $pass ) == $password ) { / / user i s a u t h e n t i c a t e d −> c r e a t e s e s s i o n ... return true ; } else { throw new E xc e p t i o n ( ’ Could n o t l o g i n . Please check your i n p u t ! ’ ) ; } } else { / / no p o s s i b l e user throw new E xc e p t i o n ( ’ Could n o t l o g i n . Please check your i n p u t ! ’ ) ; } }
Aangezien invoer van de gebruiker niet te vertrouwen is, wordt gecontroleerd of het studentennummer ( $user) een numerieke waarde is. Indien dit niet zo is, wordt er een exceptie gegooid en de code daar afgebroken. Op deze manier is het aanmelden beschermd tegen aanvallen met SQL-injection [4]. Een malafide gebruiker zou, indien de invoer van de gebruikers niet wordt gecon-
14
3.3 Ontwerp login systeem
Variabele
Gebruik
$_SESSION[’login_id’]
Bevat het studentennummer waarmee is ingelogd
$_SESSION[’login_name’]
Voornaam
$_SESSION[’login_lastname’]
Achternaam
$_SESSION[’login_role’] $_SESSION[’login_time’]
Tijdstip van inloggen
$_SESSION[’login_ip’]
IP-adres bij inloggen
$_SESSION[’login_agent’]
md5(Browser bij inloggen)
Tabel 3.1: Sessie variabelen voor Login troleerd, extra SQL opdrachten kunnen toevoegen1 . Op die manier is het eventueel mogelijk om gegevens te verwijderen of toe te voegen aan de database en in het slechtste geval zelfs ongeoorloofde toegang te krijgen tot het webplatform. Een andere aanval op de aanmeldingsprocedure zou het overnemen van de sessie kunnen zijn op basis van het sessie-id dat standaard wordt meegegeven met een cookie. Een malafide gebruiker zou het sessie-id kunnen weten of achterhalen door pakketten te onderscheppen of door een analoge methode. Om dit moeilijker te maken worden extra variabelen gebruikt. Bij het aanmelden wordt het IP-adres en de user agent opgeslagen [8]. Bij elke nieuwe controle of de gebruiker al dan niet ingelogd is worden de opgeslagen waarden met elkaar vergeleken. Indien deze niet gelijk zijn aan elkaar wordt de gebruiker afgemeld (Zie broncode 3.3). De wachtwoorden worden onleesbaar in de database opgeslagen door deze om te zetten met een
sha1 hash-functie. Ondanks het feit dat de md5 hash-functie nog steeds veel wordt gebruikt, is sha1 veel sterker en geniet het dus de voorkeur. Het zou nog veiliger zijn om de hash te genereren met toevoeging van een lange willekeurige salt aan het wachtwoord. Aangezien het hier tijdelijke wachtwoorden betreft, werd dit niet belangrijk geacht. Theoretisch gezien is het mogelijk om met brute force alle wachtwoorden te testen voor een gegeven gebruikersnaam. Dit zal echter zeer lang duren aangezien er enorm veel verschillende wachtwoorden zijn (bestaande uit acht tekens met één speciaal teken). Om dit tegen te gaan kan een maximaal aantal pogingen in een bepaald tijdsinterval worden vastgelegd. Dit werd echter niet relevant gevonden voor deze toepassing (een student die met brute force een login kan kraken had immers even 1
Voor de query in broncode 3.2 zou volgende toevoeging kunnen worden gebruikt: ’test’ AND 1=1; SELECT *
FROM users . Dit wordt SQL-injection genoemd. Andere voorbeelden liggen uiteraard voor de hand.
3.4 Ontwerp willekeurige wachtwoord generator
15
goed zijn examen kunnen oplossen). Een beveiligingsprobleem dat echter niet door een computer kan worden opgelost is het menselijke aspect. Wachtwoorden kunnen nog steeds worden doorgegeven. Broncode 3.3: Methode isloggedin 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
public s t a t i c function isloggedin ( ) { i f ( i s s e t ( $_SESSION [ ’ l o g i n _ i d ’ ] ) ) { i f ( $_SESSION [ ’ l o g i n _ t i m e ’ ] + 60 ∗ 60 ∗ 4 < t i m e ( ) ) { s e l f : : logout ( ) ; return false ; } i f ( $_SESSION [ ’ l o g i n _ a g e n t ’ ] == sha1 ($_SERVER [ ’ HTTP_USER_AGENT ’ ] ) && $_SESSION [ ’ l o g i n _ i p ’ ] == $_SERVER [ " REMOTE_ADDR " ] ) { return true ; } else { return false ; } } else { return false ; } }
Indien noodzakelijk kan een extra controle worden uitgevoerd op basis van het IP-adres. Indien het adres uit het bereik 157.193.*.* komt, heeft de gebruiker toegang tot de pagina’s aangezien de aanvraag vanuit het UGent netwerk (of VPN) komt. Deze controle kan gebeuren met PHP of bij de configuratie van de webserver.
3.4
Ontwerp willekeurige wachtwoord generator
Voor het genereren van willekeurige wachtwoorden wordt de klasse RandomPassword gebruikt. Een wachtwoord bestaat uit zeven willekeurige verschillende (hoofd)letters en cijfers (62 mogelijke karakters) met toevoeging van één speciaal karakter (25 mogelijkheden). Het speciale karakter kan voorkomen op eender welke plaats in het wachtwoord. Om geen dubbel karakter te hebben per wachtwoord wordt de array geschud waarna de eerste zeven karakters worden genomen. Voor de volgende vier wachtwoorden wordt dan telkens de volgende reeks karakters gekozen alvorens de array opnieuw te schudden. Een willekeurig speciaal karakter wordt toegevoegd en de verkregen string wordt opnieuw geschud (Broncode 3.4).
3.5 Ontwerp pdf ondersteuning
16
Broncode 3.4: Principe generator willekeurige wachtwoorden 1 2 3 4 5 6 7 8 9 10
p u b l i c f u n c t i o n generateNextPassword ( ) { i f ( $ t h i s −> i %5==0) { s h u f f l e ( $ t h i s −> l e t t e r s ) ; } $ o f f s e t =( $ t h i s −> i %5) ∗ 7 ; $pass = implode ( ’ ’ , a r r a y _ s l i c e ( $ t h i s −> l e t t e r s , $ o f f s e t , 7 , f a l s e ) ) ; $c = $ t h i s −>s p e c i a l [ rand ( 0 , count ( $ t h i s −>s p e c i a l ) −1) ] ; ++ $ t h i s −> i ; r e t u r n s t r _ s h u f f l e ( $pass . $c ) ; }
3.5 3.5.1
Ontwerp pdf ondersteuning Overerving
De klasse FPDF werd uitgebreid met de klasse Pdf om verschillende redenen. De klasse bevat methoden om kop- en voetteksten te plaatsen die automatisch worden opgeroepen bij het maken van een nieuwe pagina. Deze methoden hebben standaard geen implementatie en moeten dus bij overerving worden overschreven. Een andere reden is de eenvoudige implementatie van extra methoden. Zo werd er een methode toegevoegd om te controleren of de cursor al op een nieuwe lijn staat. Deze functionaliteit was niet aanwezig en bewijst zijn nut bij extra methoden om titels te plaatsen op basis van gedefinieerde stijlen. Voor het plaatsen van broncode en tabellen werden methodes gedefinieerd om de lay-out te voorzien.
3.5.2
Syntaxiskleuring voor broncode
De syntaxiskleuring wordt gerealiseerd door de code te vertalen naar een vorm van HTML als intermediair formaat. Zo worden de lijnen in de broncode die commentaar bevatten, bijvoorbeeld tussen
tags geplaatst. Deze tags worden geplaatst met behulp van reguliere expressies en de PHP functie preg_replace. Een minimaal voorbeeld wordt getoond in broncode 3.5. De tags worden verwerkt door de volledige tekst te splitsen op basis van een reguliere expressie. Door te itereren over de array is het mogelijk om de stijl aan te passen telkens wanneer er een tag wordt gedetecteerd. Alvorens deze tekst te splitsen worden de, veelvuldig gebruikte, groter en kleiner dan symbolen omgezet naar hun equivalent in HTML. Een minimaal voorbeeld wordt getoond in broncode 3.6 waarbij de minder relevante code werd weggelaten.
3.5 Ontwerp pdf ondersteuning
17
Broncode 3.5: Syntaxiskleuring: principe plaatsen tags 1 2 3
$ t h i s −>blockcomment_regex = ’ / ( \ / \ ∗ . ∗ \ ∗ \ / ) / Uis ’ ; ... $code = p r e g _ r e p l a c e ( $ t h i s −>blockcomment_regex , ’ < blockcomment >$1 < / blockcomment > ’ , $code ) ;
3.5.3
Pagina toevoegen aan een pdf-bestand
Bij het toevoegen van nieuwe studenten worden de gegenereerde wachtwoorden in een pdfdocument verzameld. Indien er extra toevoegingen worden gedaan komen deze studenten op een nieuwe pagina. FPDI voorziet de mogelijkheid om een bestaand pdf-document toe te voegen aan een nieuw pdf-document [6]. Aangezien de klasse FPDI overerft van de klasse FPDF werd er gekozen om de klasse Pdf over te laten erven van de klasse FPDI.
3.5.4
Samenvoegen van pdf-bestanden
Per student wordt één enkel pdf-bestand gegenereerd. De beheerder heeft de mogelijkheid om per examen een globaal pdf-document te genereren. Hiervoor wordt pdftk, een command line programma, gebruikt [7]. Aangezien pdftk zowel op Linux als op Windows beschikbaar is geniet deze tool de voorkeur.
3.5.5
Samenvatting
Om extra functionaliteit te realiseren werd de klasse FPDF uitgebreid via overerving. Een overzicht wordt gegeven door figuur 3.6. Broncode 3.6: Syntaxiskleuring: verwerken tags 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
$ s p l i t = p r e g _ s p l i t ( ’ / ( < . ∗ > ) / U’ , $code , − 1 ,PREG_SPLIT_DELIM_CAPTURE ) ;
$comment= f a l s e ; $blockcomment= f a l s e ; f o r e a c h ( $ s p l i t as $index => $ t e x t ) { i f ( preg_match ( ’ / < . ∗ > / ’ , $ t e x t ) ==0) { / / t e x t i s n o t a t a g $text = str_replace ( ’& l t ; ’ , " < " , $text ) ; $text = str_replace ( ’& gt ; ’ , " > " , $text ) ; i f ( s t r l e n ( $ t e x t ) >0) { $ t h i s −>w r i t e A t C u r s o r ( $ t e x t ) ; } } else {
18
3.5 Ontwerp pdf ondersteuning 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
i f ( $ t e x t == ’ < blockcomment > ’ ) { $ t h i s −>s e t S t y l e ( ’ codecomment ’ ) ; $blockcomment=True ; } i f ( $ t e x t == ’ < / blockcomment > ’ ) { $ t h i s −>s e t S t y l e ( ’ code ’ ) ; $blockcomment= f a l s e ; } ... / / L i n e breaks & t a b s i f ( $ t e x t == ’ < t > ’ ) { $ t h i s −>SetX ( $ t h i s −>GetX ( ) + $ t h i s −>t a b _ w i d t h ) ; } i f ( $ t e x t == ’ < br > ’ ) { $ t h i s −>Ln ( ) ; } i f ( ! $comment && ! $blockcomment ) { / / n o t i n comment mode −> h i g h l i g h t i f ( $ t e x t == ’ < keyword > ’ ) { $ t h i s −>s e t S t y l e ( ’ codekeyword ’ ) ; } ... } } } $ t h i s −>s e t S t y l e ( $ o l d s t y l e ) ;
Pdf
FPDF
#$styles +__construct($orientation = 'P', $unit = 'mm', $format = 'A4') +newStyle(...) +newTitleStyle(...) +isNewLine() +setNormalStyle() +setStyle($style) +makeTitle($style, $text) +writeAtCursor($text) +addTable($header, $data, $style = 'normal') +setMatlab() +setJava() +addCodeFile($titlestyle, $path) +addCode($code) +setHeaderContents($left = '', $center = '', $right = '') +setFooterContents($left = '', $center = '', $right = '') +Header() +Footer()
Figuur 3.6: UML model van de pdf gerelateerde klassen
FPDF_TPL
FPDT
3.6 Ontwerp klasse Exam
3.6
19
Ontwerp klasse Exam
Het opslaan van van een examen in het geheugen voor eenvoudige verwerking, controle, HTML uitvoer enz. gebeurt met behulp van twee klassen, namelijk Exam en Problem. Een UML-model van beide klassen is weergegeven in figuur 3.7. Een examen bestaat uit een aantal problemen waarbij elk probleem een aantal regels kan bevatten. Om deze boomstructuur, met drie niveaus, eenvoudig te kunnen opslaan, wordt er bij de klasse Exam een array van instanties van de klasse
Problem bijgehouden. Elk probleem bevat een tweedimensionale array. In deze array worden de verschillende inhoudsregels (zie ook 3.2.1) die door de assistenten per vraag werden gedefiniëerd, bijgehouden. Per inhoudsregel wordt in de array het type (reguliere expressie, bestandsnaam of zoekstring), de te zoeken string, en de foutmelding van die regel bijgehouden. Deze aanpak maakt het mogelijk om op een eenvoudige manier, met twee lussen, over een volledig examen te itereren. Deze aanpak levert enkele belangrijke voordelen op. Slechts één klasse is verantwoordelijk voor het verkrijgen van de examengegevens uit de database, zodat minimale wijzigingen in de database geen aanpassing van elke afzonderlijke pagina vereisen. Tevens kan een examen worden opgeslagen in een sessievariabele. Dit maakt het mogelijk om, zonder ingewikkelde Javascripts te gebruiken, de toestand te bewaren bij het toevoegen of aanpassen van een examen. Vermijden van Javascript zorgt voor een systeem dat meer browser onafhankelijk is. De klassen voorzien ook in enkele methoden om een pdf-bestand te genereren van de geüploade bestanden voor een bepaald examen. Hiervoor dient o.a. het pad meegegeven te worden. Deze methoden geven een FPDF-object terug, zodat, onafhankelijk van de implementatie in deze klassen, het pdf-document kan worden opgeslagen voor eender welk pad of eventueel direct kan worden meegestuurd met de browser voor een inline weergave (bijvoorbeeld voor de preview). Tijdens het genereren van het pdf-bestand kan, zoals bijvoorbeeld voor het pdf-document dat achteraf verbeterd wordt, voor elk .java bestand worden getest of het al dan niet compileert. Indien er foutmeldingen zijn, worden deze weergegeven. Het compileren van deze bestanden vereist uiteraard dat de java compiler vanuit elke map kan worden opgeroepen2 . Het compileren gebeurt zoals weergegeven in broncode 3.7. Aangezien de PHP-functie exec enkel de stdout leest en javac enkel op stderr schrijft wordt de stderr naar de stdout verwezen. Om veiligheidsredenen wordt de bestandsnaam van het te compileren bestand meegegeven tussen aanhalingstekens.
2
Op Linux is dit standaard terwijl op Windows het juiste pad aan de PATH variabele moet worden toegevoegd.
20
3.7 Ontwerp beheerders gedeelte Exam
Problem
+$name +$problems +$numberOfProblems +$date
+$description +$name +$rules +$numberOfFiles
+__construct($name, $date) +addProblem($problem) +deleteLastProblem() +checkFromPath($path) +color($numberOfFiles, $satisfied) +toHtml() +toPDF(...) +toPDFadmin(...) +createFromSQL($id, &$mysqli_object)
+__construct($name, $description) +addRule($type, $searchstring, $errormessage) +allRulesSatisfied() +errorMessage()
Pdf
Figuur 3.7: UML-model van klasse Exam e.a. Broncode 3.7: Compileren java bestanden 1 2 3 4 5
... $stdout = ’ ’ ; $ r e t u r n v a l u e = −1; exec ( " j a v a c \ " $ f i l e \ " 2 >&1" , $ s t d o u t , $ r e t u r n v a l u e ) ; ...
3.7 3.7.1
Ontwerp beheerders gedeelte Toevoegen en aanpassen van een examen
Bij het aanmaken van een nieuw examen of het bewerken van een bestaand examen worden de gegevens bijgehouden in een Exam object als sessievariabele. Telkens wanneer er een probleem of een regel wordt toegevoegd of verwijderd aan het formulier, wordt de sessievariabele ook aangepast. Bij het toevoegen of verwijderen van een probleem of een regel wordt de sessievariabele immers terug aangevuld met de gegevens uit de browser van de gebruiker. Het formulier moet dus worden verzonden bij elke actie op die pagina. Dit wordt gerealiseerd door met Javascript elke mogelijke link bij het aanklikken als actie te plaatsen van het formulier en daarna het formulier te verzenden (Broncode 3.8). Bij diezelfde functie wordt dan eveneens een bevestiging gevraagd bij het verwijderen van gegevens. Het toevoegen van het examen gebeurt analoog. Een Javascript functie zal, alvorens het formulier te verzenden, controleren of alle invoervelden zijn ingevuld. Bij het aanpassen van een examen wordt eerst, op basis van het gegeven examen-id, het oude examen opgebouwd als sessievariabele. De volledige pagina werkt vanaf dan analoog als bij het maken van een nieuw examen. Bij het uiteindelijke verzenden van het examen zal eerst het oude examen
3.7 Ontwerp beheerders gedeelte
21
verwijderd worden. Hierna wordt het aangepaste examen als een nieuw examen toegevoegd. Na het verwijderen wordt het oude examen-id gerestaureerd en wordt de auto increment waarde ook terug verlaagd. Dit laatste gebeurt om niet bij elke wijziging van een examen het id van het volgende nieuwe examen nodeloos te verhogen. Het examen-id mag na het wijzigen zeker niet veranderen, omdat, indien er al studenten aangemeld zouden zijn, dit id in een sessievariabele staat. Broncode 3.8: Javascript submit functie 1 2 3 4 5 6 7 8 9 10
f u n c t i o n submit ( l i n k ) { v a r ans = t r u e ; i f ( l i n k . indexOf ( ’ d e l e t e ’ , 0 ) >=0) { ans = c o n f i r m ( " Are you sure you want t o d e l e t e ? " ) ; } i f ( ans ) { document . getElementById ( " examform " ) . a c t i o n = l i n k ; document . getElementById ( " examform " ) . submit ( ) ; } }
3.7.2
Uploaden en downloaden van een studentenlijst
Een beheerder kan via de pagina List exams een overzicht krijgen van alle examens die aanwezig zijn in de database. Op deze pagina is het ook mogelijk studentenlijsten toe te voegen aan een examen. Bij het uploaden van de studentenlijst worden studenten automatisch toegevoegd aan de users en registration tabellen in de database. Op dat moment worden ook de wachtwoorden voor deze studenten aangemaakt. Van de wachtwoorden wordt enkel de uitkomst van de SHA-1 hash-functie (zie login onder 3.3) in de database opgeslagen. Terugkeren van deze onleesbaar opgeslagen wachtwoorden naar het oorspronkelijke wachtwoord is niet mogelijk, maar op het examen zelf moet wel een lijst met de wachtwoorden kunnen worden uitgedeeld. Deze lijst moet dus op het moment dat de wachtwoorden worden gegenereerd, worden aangemaakt. De lijst wordt opgeslagen onder de vorm van een pdf-document in de map upload. Wanneer meerdere studentenlijsten worden geüpload, worden deze toegevoegd aan het reeds bestaande pdf-bestand. Op de pagina List exams is de mogelijkheid voorzien om de studentenlijst van elk examen te downloaden. Naast het updaten van de database, worden ook de persoonlijke mappen van de studenten aangemaakt op de server. De studenten worden hiervoor ingedeeld per reeks en PC-klas. In de map van de student, aangeduid met zijn studentennummer, wordt per probleem dat het examen bevat, een submap gemaakt. Indien de map van de student al bestond wordt een waarschuwing gegeven, want dit betekent dat de student al in een vorige lijst aanwezig was. Aangezien in zowel
3.8 Aanpassen configuratie variabelen
22
de tabel users als registration het studentennummer een unieke waarde is, wordt de student niet opnieuw toegevoegd. Zijn wachtwoord wordt echter wel gewijzigd, vandaar het belang van deze waarschuwing.
3.7.3
Overzicht studenten
Een overzicht van alle studenten die voor een examen zijn geregistreerd, wordt bekomen via de link List students op de overzichtspagina van de examens. Op deze pagina staan alle studenten alfabetisch gerangschikt, wordt gecontroleerd of hun persoonlijke mappen zijn aangemaakt en worden de bestanden in deze mappen weergegeven. Er wordt aangegeven of de student het examen reeds heeft ingediend, en dit kan in noodgevallen via deze pagina ook ongedaan worden gemaakt. Verder is het mogelijk om het wachtwoord van een student te wijzigen en de student te verwijderen uit dit examen. Wanneer een student wordt verwijderd, wordt de database aangepast en worden zijn persoonlijke mappen (en de eventueel daarin aanwezige bestanden) eveneens verwijderd. Uiteraard worden bij deze laatste links steeds waarschuwingen gegenereerd via Javascript, aangezien deze acties in definitieve wijzigingen resulteren.
3.8
Aanpassen configuratie variabelen
Enkele globale configuratie variabelen, zoals het al dan niet toelaten van binaire bestanden en de paden naar de verschillende mappen, worden vastgelegd in het bestand config.php. Om deze waarden te kunnen veranderen, werd een kleine interface gebouwd die dat toestaat. Aangezien het niet onwaarschijnlijk is dat er nog extra variabelen aan dit bestand worden toegevoegd, is geopteerd om het wijzigen van deze waarden te doen door het weergeven van het volledige bestand. Bij wijziging wordt de inhoud van het formulier dan weggeschreven in het bestand. Aanpassen van de waarden vereist dus een minimale kennis van PHP en het bestand moet uiteraard lees- en schrijfbaar zijn door de gebruiker die PHP aanroept op de server.
23
3.9 Ontwerp studenten gedeelte
3.9
Ontwerp studenten gedeelte
De student krijgt na het invoeren van zijn wachtwoord enkel toegang tot een overzichtspagina (zie figuur 3.8). Op deze pagina is de mogelijkheid voorzien om bestanden te uploaden naar zijn persoonlijke map. De bestanden die in deze map aanwezig zijn, worden weergegeven en kunnen van hieruit verwijderd worden. Op deze pagina wordt ook onmiddellijke feedback gegeven over de status van het examen. De student kan tenslotte een preview van zijn examen bekijken en het examen indienen.
Figuur 3.8: Overzichtspagina
3.9 Ontwerp studenten gedeelte
3.9.1
24
Login
In de klasse Login werd een aparte methode studentLogin voorzien die enkele bijkomende sessievariabelen aanmaakt bij het aanmelden van een student. Het gaat hierbij om het examen-id, het pad naar de persoonlijke map van de student, een variabele die aanduidt of het examen reeds werd ingediend, en de vragen die als blanco gemarkeerd zijn. Er werd geopteerd om deze gegevens in sessievariabelen bij te houden, omdat deze door verschillende pagina’s worden gebruikt. Zodoende moeten deze niet altijd uit de database worden uitgelezen. In principe kan per student dan ook zijn examen worden bijgehouden in een sessievariabele. Dit werd niet gedaan omdat er geen garantie is dat de sessievariabelen enkel gelezen kunnen worden door diegene die de sessie heeft aangemaakt [4].
3.9.2
Overzicht examen
Weergave bestanden Voor de weergave van de bestanden werd gebruik gemaakt van een klasse Dir. In deze klasse werden een aantal functies geconstrueerd die het mogelijk maakten om bestanden in de persoonlijke map van de student weer te geven en te verwijderen.
Blanco optie Voor de verwerking van de blanco vragen wordt in een sessievariabele een array bijgehouden die per vraag bijhoudt of deze al dan niet als blanco werd aangeduid. Deze gegevens zijn niet persistent, aangezien de sessievariabele bij uitloggen wordt verwijderd. Dit impliceert dat bij het uitloggen de vragen die stonden aangeduid als blanco terug zichtbaar zijn, maar geen bestanden bevatten. Aangezien de student zijn examen niet kan indienen wanneer vragen leeg zijn, zou dit niet voor problemen mogen zorgen. Het zou uiteraard idealer zijn om deze gegevens persistent te maken in de database. Als de variabele in de array $_SESSION[’blank’], met als index het nummer van de opgave, niet bestaat dan is de betreffende opgave niet blanco. Indien de variabele wel bestaat is de opgave dus blanco en worden de eventueel geüploade bestanden verwijderd (Broncode 3.9).
3.9 Ontwerp studenten gedeelte Broncode 3.9: Implementatie blanco optie 1 2 3 4 5 6 7 8 9 10
i f ( i s s e t ( $_GET [ ’ blank ’ ] ) ) { i f ( i s s e t ( $_SESSION [ ’ blank ’ ] [ $_GET [ ’ blank ’ ] ] ) ) { unset ( $_SESSION [ ’ blank ’ ] [ $_GET [ ’ blank ’ ] ] ) ; } else { $_SESSION [ ’ blank ’ ] [ $_GET [ ’ blank ’ ] ] = t r u e ; $ d i r e c t o r y =new D i r ( $_SESSION [ ’ path ’ ] . " / problem_ " . $_GET [ ’ blank ’ ] ) ; $ d i r e c t o r y −>D e l e t e D i r ( t r u e ) ; / / t r u e means t h a t o n l y c o n t e n t s are d e l e t e d } }
25
26
DEMO
Hoofdstuk 4
Demo 4.1
Assistent
In figuur 4.1 is het venster weergegeven waarin een beheerder (of assistent) een nieuw examen kan aanmaken. Een examen wordt gekenmerkt door een naam en een datum. Via de knoppen aan de rechterkant, kunnen vragen (problems) worden toegevoegd. Deze vragen hebben opnieuw een naam en bevatten ook een beschrijving van het probleem dat moet worden opgelost. Bij elke vraag kunnen verschillende regels (rules) worden gedefinieerd. De beheerder kan hierbij ook de foutmelding invullen die wordt weergegeven indien niet aan deze regel wordt voldaan. Tenslotte kan de beheerder het examen in de database opslaan via de link onderaan de pagina.
27
4.1 Assistent
Figuur 4.1: Toevoegen van een nieuw examen
Figuur 4.2: Oplijsten van de toegevoegde examens
28
4.1 Assistent
Wanneer de assistent op de link list exams klikt, wordt een overzicht getoond van alle examens die aanwezig zijn in de database. Dit overzicht wordt getoond in figuur 4.2. De eerste drie kolommen van de tabel vormen de weergave van de tabel exams in de database. In de laatste kolom zijn de acties die de beheerder per examen kan uitvoeren gespecificeerd. De link List students brengt de beheerder naar een pagina die getoond wordt in figuur 4.3. Op deze pagina worden alle studenten die geregistreerd zijn voor een examen opgelijst. Door op de links onder de vragen te klikken, kan de begeleider een overzicht krijgen van de bestanden die voor deze vraag door de student werden geüpload. Dit gebeurt via een pop-up venster. In de vijfde kolom wordt via een icoon weergegeven of het examen al werd ingediend. Wanneer dit inderdaad zo is, kan de beheerder dit ongedaan maken door op het icoontje te klikken. Uiteraard wordt hierbij eerst een waarschuwing gegeven. De laatste kolom bevat opnieuw de acties die een beheerder voor een bepaalde student kan uitvoeren (student verwijderen en wachtwoord wijzigen). Wanneer de beheerder op deze acties klikt, wordt via een pop-up ook een waarschuwing gegenereerd.
Figuur 4.3: Overzicht van de status van een examen voor alle studenten
29
4.1 Assistent
Figuur 4.4: Aanpassen van de configuratie variabelen Het aanpassen van de configuratie variabelen, die opgeslagen zijn in het bestand config.php op de server, kan eenvoudig gebeuren via het venster dat weergegeven wordt in figuur 4.4. De volledige bestandsinhoud wordt in het kader weergegeven en kan hierin gewijzigd worden. Door op de knop Save te klikken wordt de tekst in het kader opnieuw weggeschreven naar het bestand.
30
4.2 Student
4.2
Student
Figuur 4.5: Overzicht van het studentengedeelte Wanneer een student is ingelogd, ziet hij enkel het scherm dat wordt weergegeven in figuur 4.5. In de linkerkolom worden de bestanden opgelijst die de student heeft geüpload. Rechts daarvan kan hij een bestand kiezen om bij een bepaalde vraag te uploaden. Via kleurcodes en tekst wordt, onder het uploadformulier, de status van een vraag getoond. Wanneer de student op één van deze statussen klikt, wordt een pop-up geopend waarin hij meer informatie krijgt over wat er precies bij deze vraag ontbreekt. De informatie die hij hier te zien krijgt, bestaat uit de foutmeldingen die de
31
4.2 Student beheerder opgeeft bij elke regel van een vraag in een examen.
Wanneer een student een vraag niet wil of kan beantwoorden, en dus geen bestanden kan uploaden, dient hij op de link Mark as blank te klikken. Dit kan uiteraard weer ongedaan gemaakt worden via de link die verschijnt na het als blanco markeren van de vraag. (Zie figuur 4.5: Problem 4) Onderaan de pagina kan de student via de linkerlink een preview van zijn examen bekijken in pdfformaat. Wanneer hij op de link Submit klikt, kan hij zijn examen indienen.
Figuur 4.6: Indienen examen Voor het indienen van het examen wordt een pop-up gegenereerd die wordt getoond in figuur 4.6. De student krijgt in deze pop-up een duidelijk overzicht van de staat van zijn examen. In dit voorbeeld kan de student zijn examen nog niet definitief indienen, omdat bij vraag drie geen bestanden werden geüpload en deze vraag nog niet als blanco werd aangeduid. Hij wordt hiervan dan ook op de hoogte gebracht in de pop-up. Wanneer bij alle vragen bestanden aanwezig zijn of deze als blanco gemarkeerd zijn, kan de student ervoor kiezen om definitief in te dienen. Hiervoor bevindt zich op dat moment een Submit knop onderaan het pop-up venster.
TOEKOMSTIG WERK EN BESLUIT
32
Hoofdstuk 5
Toekomstig werk en besluit Dit hoofdstuk bevat een korte beschrijving van eventueel toekomstige verbeteringen die aan het systeem kunnen worden aangebracht. Om te eindigen wordt een kort besluit en overzicht geven van het ontwikkelde webplatform.
5.1
Toekomstig werk
Tijdens de implementatie bleek dat niet altijd de beste methode werd gekozen om een bepaalde functionaliteit toe te voegen. Deze sectie bevat een overzicht van enkele functionaliteiten die mogelijk beter geïmplementeerd zouden kunnen worden.
5.1.1
Examenbegeleiders
Ondanks het feit dat begeleiders voorzien zijn in de database is deze functionaliteit niet geïmplementeerd. Een opsplitsing tussen beheer en begeleider zou het toestaan om aan elk examen één begeleider toe te wijzen. Deze begeleider zou dan enkel de details van het aan hem toegewezen examen mogen bekijken en aanpassen. Op die wijze wordt de mogelijkheid dat fouten gemaakt worden, verkleind aangezien de begeleider geen aanpassingen kan doen in andere examens.
5.1.2
Foutafhandeling
In de huidige versie van het webplatform is er geen eenduidige foutafhandeling. Op de meeste plaatsen wordt er bij een onverwachte fout een boodschap uitgeschreven. Dit kan bijvoorbeeld half gegenereerde pagina’s weergeven aan de gebruiker [10]. Het zou beter zijn om bij elke mogelijke fout een exceptie te gooien met bijhorende foutboodschap. Als al deze excepties worden opgevan-
33
5.1 Toekomstig werk
gen voor de volledige pagina is het mogelijk om door de buffer leeg te maken één uniforme pagina weer te geven met de fout. Een voorbeeld van een mogelijk raamwerk wordt gegeven in broncode 5.1. Broncode 5.1: Betere foutafhandeling 1 2 3 4 5 6 7 8 9 10 11
getMessage ( ) ) ; } ?>
5.1.3
Unit testen
Theoretisch gezien is het ook mogelijk om per vraag een testcase op te stellen met JUnit. Op basis van deze testcase kan dan bepaald worden of de opgave al dan niet correct is opgelost. Dit zou betekenen dat de opgaven enkel nog moeten worden nagekeken wat betreft stijl en efficiëntie. Indien de unit test faalt, moet uiteraard de opgave volledig manueel worden verbeterd.
5.1.4
Aanpassen configuratievariabelen
Momenteel worden de configuratievariabelen gewijzigd door de beheerder manueel het bestand config.php te laten aanpassen met een web formulier. Het zou veel efficiënter en met minder kans op fouten gebeuren indien er per variabele een invoerveld wordt aangemaakt waarin de aanpassing kan gebeuren. De nodige uitleg kan dan ook in PHP worden verkregen uit commentaar in het configuratie bestand. Het bestand zou dan een vast gedefinieerd formaat moeten krijgen. Na wijziging, kan het bestand dan terug volgens dit vaste formaat worden weggeschreven.
5.2 Besluit
5.2
34
Besluit
Een webplatform werd ontwikkeld om op eenvoudige wijze het indienen van broncode bestanden bij examens te automatiseren. Elke student verkrijgt een persoonlijke account die de details van het door hem af te leggen examen bevat. Via deze account kan hij bij elke vraag zijn oplossing als broncode indienen. Na elk examen kan de beheerder een pdf-bestand genereren met de geüploade broncode gerangschikt per student en uiteraard per vraag. Om een gemakkelijke verbetering mogelijk te maken is de afdruk van broncode voorzien van een syntaxiskleuring. Door een strakke definiëring van het examen en de bestandsinhoud, wordt de verantwoordelijkheid van het correct indienen volledig bij de student gelegd. Deze aanpak vermijdt discussies die zouden kunnen ontstaan bij verlies van gegevens.
35
DATABASE SQL-QUERY
Bijlage A
Database SQL-query Onderstaande SQL-query maakt een database zoals beschreven in 3.2. Broncode A.1: Database SQL 1 SET SQL_MODE= "NO_AUTO_VALUE_ON_ZERO" ; 2 3 CREATE DATABASE ‘ m a s t e r p r o e f m t i ‘ DEFAULT CHARACTER SET l a t i n 1 COLLATE latin1_swedish_ci ; 4 USE ‘ m a s t e r p r o e f m t i ‘ ; 5 6 CREATE TABLE I F NOT EXISTS ‘ c o n t e n t r u l e s ‘ ( 7 ‘ i d ‘ i n t ( 1 1 ) NOT NULL AUTO_INCREMENT, 8 ‘ problemid ‘ i n t ( 1 1 ) NOT NULL, 9 ‘ type ‘ t i n y t e x t NOT NULL, 10 ‘ s e a r c h s t r i n g ‘ l o n g t e x t NOT NULL, 11 ‘ errormessage ‘ t e x t NOT NULL, 12 PRIMARY KEY ( ‘ i d ‘ , ‘ problemid ‘ ) , 13 KEY ‘ problemid ‘ ( ‘ problemid ‘ ) 14 ) ENGINE=InnoDB DEFAULT CHARSET= l a t i n 1 ; 15 16 CREATE TABLE I F NOT EXISTS ‘ exams ‘ ( 17 ‘ i d ‘ i n t ( 1 1 ) NOT NULL AUTO_INCREMENT, 18 ‘ date ‘ date NOT NULL, 19 ‘ name ‘ t e x t NOT NULL, 20 PRIMARY KEY ( ‘ i d ‘ ) 21 ) ENGINE=InnoDB DEFAULT CHARSET= l a t i n 1 ; 22 23 CREATE TABLE I F NOT EXISTS ‘ problems ‘ ( 24 ‘ i d ‘ i n t ( 1 1 ) NOT NULL AUTO_INCREMENT, 25 ‘ examid ‘ i n t ( 1 1 ) NOT NULL, 26 ‘ name ‘ t e x t NOT NULL, 27 ‘ d e s c r i p t i o n ‘ t e x t NOT NULL, 28 PRIMARY KEY ( ‘ i d ‘ , ‘ examid ‘ ) , 29 KEY ‘ examid ‘ ( ‘ examid ‘ ) 30 ) ENGINE=InnoDB DEFAULT CHARSET= l a t i n 1 ; 31
DATABASE SQL-QUERY 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65
CREATE TABLE I F NOT EXISTS ‘ r e g i s t r a t i o n ‘ ( ‘ i d ‘ i n t ( 1 1 ) NOT NULL AUTO_INCREMENT, ‘ nr ‘ i n t ( 1 1 ) NOT NULL, ‘ examid ‘ i n t ( 1 1 ) NOT NULL, ‘ groupid ‘ i n t ( 1 1 ) NOT NULL, ‘ a u d i t o r i u m ‘ t e x t NOT NULL, ‘ submitted ‘ t i n y i n t ( 4 ) NOT NULL DEFAULT ’ 0 ’ , PRIMARY KEY ( ‘ i d ‘ , ‘ nr ‘ , ‘ examid ‘ ) , UNIQUE KEY ‘ nr ‘ ( ‘ nr ‘ ) , KEY ‘ examid ‘ ( ‘ examid ‘ ) ) ENGINE=InnoDB DEFAULT CHARSET= l a t i n 1 ; CREATE TABLE I F NOT EXISTS ‘ users ‘ ( ‘ i d ‘ i n t ( 1 1 ) NOT NULL AUTO_INCREMENT, ‘ name ‘ t e x t NOT NULL, ‘ lastname ‘ t e x t NOT NULL, ‘ nr ‘ i n t ( 1 1 ) NOT NULL, ‘ password ‘ t e x t NOT NULL, ‘ role ‘ t e x t NOT NULL, PRIMARY KEY ( ‘ i d ‘ ) , UNIQUE KEY ‘ nr ‘ ( ‘ nr ‘ ) ) ENGINE=InnoDB DEFAULT CHARSET= l a t i n 1 ; ALTER TABLE ‘ c o n t e n t r u l e s ‘ ADD CONSTRAINT ‘ c o n t e n t r u l e s _ i b f k _ 1 ‘ FOREIGN KEY ( ‘ problemid ‘ ) REFERENCES ‘ problems ‘ ( ‘ i d ‘ ) ON DELETE CASCADE ON UPDATE CASCADE; ALTER TABLE ‘ problems ‘ ADD CONSTRAINT ‘ problems_ibfk_1 ‘ FOREIGN KEY ( ‘ examid ‘ ) REFERENCES ‘ exams ‘ ( ‘ i d ‘ ) ON DELETE CASCADE ON UPDATE CASCADE; ALTER TABLE ‘ r e g i s t r a t i o n ‘ ADD CONSTRAINT ‘ r e g i s t r a t i o n _ i b f k _ 3 ‘ FOREIGN KEY ( ‘ nr ‘ ) REFERENCES ‘ users ‘ ( ‘ nr ‘ ) ON DELETE CASCADE;
36
INSTALLATIE
37
Bijlage B
Installatie B.1
Mappen
Het volledige webplatform bestaat uit slechts drie mappen die alle functionaliteiten omvatten:
• web: deze map is de document root van heel het systeem. Alle bestanden in deze map zijn publiek toegankelijk.
• code: deze map bevat alle klassen, extra bibliotheken en pagina’s. Om veiligheidsredenen wordt deze map best buiten de document root geplaatst.
• upload: deze map zal alle geüploade bestanden bevatten. Om veiligheidsredenen wordt ook deze map best buiten de document root geplaatst. Deze map moet schrijfbaar zijn vanuit PHP.
B.2
Installatie procedure
1. De mappen worden geplaatst volgens de richtlijnen in paragraaf 3.1.1. 2. Het bestand config.php (in de map web) moet worden aangepast zodat de paden correct verwijzen naar de mappen code en upload. 3. Het bestand global_vars.php (in de map code ) moet de correcte gegevens bevatten voor de database. Daarna kan de database worden aangemaakt. 4. De database query (broncode A.1) kan worden gebruikt om de tabellen in de database aan te maken. 5. Als laatste stap moet een beheerder aangemaakt worden met een SQL-commando.
B.3 Vereisten
B.3
38
Vereisten
Om de volledige functionaliteit te kunnen gebruiken moeten twee extra programma’s aanroepbaar zijn vanuit PHP met de exec functie:
• pdftk1 : samenvoegen van verschillende pdf bestanden • javac: compileren van de java broncodebestanden
1
http://www.pdflabs.com/tools/pdftk-the-pdf-toolkit/
CD-ROM
Bijlage C
Cd-rom Onderstaande cd-rom bevat de volledige broncode van deze masterproef.
39
40
REFERENTIES
Referenties [1] G. DE TRE, Principes van databases, Pearson Education, (2007) [2] W. J. GILMORE, Beginning PHP and MySQL, Apress, (2008) [3] R. LERDORF, K. TATROE, Programming PHP, O’Reilly, (2002) [4] PHP DOCUMENTATION GROUP, PHP Manual, the PHP Documentation Group, (2011) [5] O. PLATHEY, FPDF Library, http://www.fpdf.org, (mei 2011) [6] J. SLABON,
FPDI - Import existing PDF documents into FPDF,
http://www.setasign.de/
products/pdf-php-solutions/fpdi/, (mei 2011) [7] S. STEWARD, pdftk - the pdf toolkit, http://www.pdflabs.com/tools/pdftk-the-pdf-toolkit/, (mei 2011) [8] L. ULLMAN, PHP 6 and MySQL 5 for Dynamic Web Sites: Visual QuickPro Guide, Peachpit Press, (2008) [9] L. WELLING, L. THOMSON,
PHP and MySQL Web Development; Addison-Wesley, 4th
edition, (2009) [10] H. E. WILLIAMS, D. LANE, Web Database Application with PHP and MySQL, O’Reilly, (2004)
41
LIJST VAN FIGUREN
Lijst van figuren 1.1 Use case diagram webplatform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
3.1 Mappenstructuur van de documentroot (web) . . . . . . . . . . . . . . . . . . . . . .
7
3.2 Mappenstructuur van de code map . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.3 Mappenstructuur van de upload map . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.4 EER-model database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.5 Tabellen in de database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.6 UML model van de pdf gerelateerde klassen
. . . . . . . . . . . . . . . . . . . . . .
18
3.7 UML-model van klasse Exam e.a. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.8 Overzichtspagina . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.1 Toevoegen van een nieuw examen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.2 Oplijsten van de toegevoegde examens . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.3 Overzicht van de status van een examen voor alle studenten . . . . . . . . . . . . . .
28
4.4 Aanpassen van de configuratie variabelen . . . . . . . . . . . . . . . . . . . . . . . .
29
4.5 Overzicht van het studentengedeelte . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.6 Indienen examen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
42
LIJST VAN BRONCODE
Lijst van broncode 3.1 Basisconcept admin.php . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.2 Methode login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.3 Methode isloggedin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.4 Principe generator willekeurige wachtwoorden
. . . . . . . . . . . . . . . . . . . . .
16
3.5 Syntaxiskleuring: principe plaatsen tags . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.6 Syntaxiskleuring: verwerken tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.7 Compileren java bestanden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.8 Javascript submit functie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.9 Implementatie blanco optie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
5.1 Betere foutafhandeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
A.1 Database SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
