NietVergeten.NL IN3700. Bachelor Project Roland Voets Dennis de Bode

NietVergeten.NL IN3700 Bachelor Project 2006

Roland Voets - 1058932 Dennis de Bode - 1027328

TU Delft, Technische Informatica Datum: 30-06-2006 Opdrachtgever: Ronald Grahmbeek TU-begeleider: Wouter de Jong Coördinator BSc.: B.R. Sodoyer

Technische Universiteit Delft

Index 1

PLAN VAN AANPAK......................................................................................................................... 4 1.1 INTRODUCTIE ................................................................................................................................. 4 1.1.1 Aanleiding................................................................................................................................. 4 1.1.2 According en bijstelling............................................................................................................ 4 1.1.3 Toelichting opbouw plan van aanpak....................................................................................... 4 1.2 PROJECTOPDRACHT ....................................................................................................................... 4 1.3 AANPAK + PLANNING .................................................................................................................... 5 1.3.1 Gantt Chart............................................................................................................................... 5 1.3.2 Aanpak algemeen...................................................................................................................... 5 1.3.3 Analyse + Ontwerp fase............................................................................................................ 6 1.3.4 Implementatie fase.................................................................................................................... 6 1.3.5 Eind fase ................................................................................................................................... 6 1.4 AFSPRAKEN ................................................................................................................................... 7 1.5 LEESWIJZER ................................................................................................................................... 8

2

REQUIREMENTS .............................................................................................................................. 9 2.1 INTRODUCTIE ................................................................................................................................. 9 2.2 FUNCTIONAL REQUIREMENTS ........................................................................................................ 9 2.2 NONFUNCTIONAL REQUIREMENTS ............................................................................................... 11 2.3 SCENARIO’S ................................................................................................................................. 11 2.3.1 Lijst Scenario’s ....................................................................................................................... 11 2.3.2 Voorbeeld: Registreren gebruiker .......................................................................................... 12 2.4 SCHERMEN................................................................................................................................... 13 2.4.1 Lijst schermen + scenario’s.................................................................................................... 13 2.4.2 Voorbeeld: Registreren Gebruiker ......................................................................................... 15

3

SECURITY......................................................................................................................................... 17 3.1 INLEIDING .................................................................................................................................... 17 3.2 LOGIN GEGEVENS ........................................................................................................................ 17 3.2.1 Risico’s ................................................................................................................................... 17 3.2.2 Maatregelen............................................................................................................................ 17 3.3 COMMUNICATIE TUSSEN GEBRUIKER EN SERVER ........................................................................ 18 3.3.1 Risico’s ................................................................................................................................... 18 3.3.2 Maatregelen............................................................................................................................ 18 3.4 GEBRUIK VAN GLOBALE VARIABELEN ......................................................................................... 18 3.4.1 Risico’s ................................................................................................................................... 18 3.4.2 Maatregelen............................................................................................................................ 19 3.5 CROSS SCRIPTING / SQL INJECTION ............................................................................................. 19 3.5.1 Risico’s ................................................................................................................................... 19 3.5.2 Maatregelen............................................................................................................................ 19 3.6 SESSIONS HIJACKING ................................................................................................................... 20 3.6.1 Risico’s ................................................................................................................................... 20 3.6.2 Maatregelen............................................................................................................................ 20 3.7 OPSLAAN VAN SCANS OP DE FTP SERVER ..................................................................................... 20 3.7.1 Risico’s ................................................................................................................................... 20 3.7.2 Maatregelen............................................................................................................................ 21 3.8 CONCLUSIE .................................................................................................................................. 21

4

SYSTEM DESIGN............................................................................................................................. 22 4.2 4.3

INTRODUCTION ............................................................................................................................ 22 ALGEMENE REGELS...................................................................................................................... 22 Bachelor Project IN3700 - 2 -


4.4 SUBSYSTEMEN ............................................................................................................................. 22 4.4.1 Subsystemen + functionaliteiten ............................................................................................. 23 Frontend: ............................................................................................................................................. 23 4.5 DATABASE ................................................................................................................................... 25 4.5.1 Database model ...................................................................................................................... 25 4.5.2 Toelichting .............................................................................................................................. 25 4.6 OBJECT GEORIËNTEERD............................................................................................................... 27 4.6.1 Klassendiagram ...................................................................................................................... 27 4.6.2 Toelichting .............................................................................................................................. 27 5

TEST DESIGN................................................................................................................................... 29 5.2 INTRODUCTION ............................................................................................................................ 29 5.3 HOE GAAN WE TESTEN? ............................................................................................................... 29 5.4 WELKE TESTEN GAAN WE UITVOEREN? ....................................................................................... 29 5.4.1 Functional Testing:................................................................................................................. 29 5.4.2 Boundary Testing: .................................................................................................................. 30 5.4.3 Pilot testing: ........................................................................................................................... 32

6

CONCLUSIES EN AANBEVELINGEN............... FOUT! BLADWIJZER NIET GEDEFINIEERD. 6.1 INLEIDING .................................................................................................................................... 33 6.2 AANPAK....................................................................................................................................... 33 6.2.1 Conclusies............................................................................................................................... 33 6.2.2 Aanbevelingen ........................................................................................................................ 33 6.3 ANALYSE + ONTWERP .................................................................................................................. 34 6.3.1 Conclusies............................................................................................................................... 34 6.3.2 Aanbevelingen ........................................................................................................................ 34 6.4 OBJECT GEORIËNTEERDE FUNCTIONALITEIT VAN PHP ................................................................ 34 6.4.1 Conclusies............................................................................................................................... 34 6.4.2 Aanbevelingen ........................................................................................................................ 34 6.5 SECURITY .................................................................................................................................... 35 6.5.1 Conclusies................................................................................................................................... 35 6.5.2 Aanbevelingen ........................................................................................................................ 35 6.6 TESTEN ........................................................................................................................................ 36 6.6.1 Conclusies............................................................................................................................... 36 6.6.2 Aanbevelingen ........................................................................................................................ 36

7

VERSION LIST ................................................................................................................................. 37

APPENDIX A: OPDRACHT OMSCHRIJVING.................................................................................... 38 APPENDIX B: REQUIREMENTS ANALYSIS DOCUMENT ............................................................. 40 APPENDIX C: SYSTEM DESIGN DOCUMENT .................................................................................. 90 APPENDIX D: TESTSCRIPTS DESIGN DOCUMENT ....................................................................... 98

Bachelor Project IN3700 - 3 -

Technische Universiteit

1

Plan van Aanpak

Plan van Aanpak

1.1 Introductie

1.1.1 Aanleiding In april beginnen wij met ons laatste traject van de Bachelor fase van onze studie Technische Informatica (Software Technologie). Deze Bachelor fase moet worden afgesloten met een stage. Na het doorspitten van de verschillende opdrachten op blackboard en voeren van gesprekken met de mensen van het bedrijf Moerstaal.nl, is de keuze gevallen op de opdracht NietVergeten.NL.

1.1.2 According en bijstelling Dit plan van aanpak is ontworpen door Roland Voets en Dennis de Bode. Het plan van aanpak zal al dan niet worden goedgekeurd door onze begeleider van de TU Delft; de heer ir. W. de Jong en de directeur van Moerstaal.nl; de heer Ronald Grahmbeek. Omdat het nog onduidelijk is of de gehele opdracht kan worden afgerond in de 10 weken die staan voor de Bachelor stage, is het mogelijk dat het plan van aanpak nog wordt aangepast. Dit zal gebeuren in overleg met de heer Ronald Grahmbeek.

1.1.3 Toelichting opbouw plan van aanpak Eerst geven we een toelichting met betrekking tot de inhoud van onze opdracht waarna we een uitleg geven met betrekking tot onze aanpak.

1.2 Projectopdracht Het is de bedoeling dat wij een site gaan maken die een soort geheugensteun is voor de gebruiker. Met geheugensteun bedoelen we dan dat de gebruiker gegevens zoals verjaardagen, sofi-nummer, vervaldatum paspoort enz, op de site kan opslaan, zodat hij die makkelijk kan terugvinden. Voor een uitgebreide omschrijving, ga naar appendix a (de opdracht omschrijving).



Plan van Aanpak

1.3 Aanpak + planning 1.3.1 Gantt Chart

Figure 1 Gantt Chart Bachelor Project 2006

1.3.2 Aanpak algemeen We werken volgens de waterfall methode, maar sommige activiteiten zullen toch incremental plaatsvinden. De functionaliteit tijdens de implementatiefase zal voornamelijk incremental worden gemaakt. Als er een bepaalde feature af is, dan wordt deze getest en zodra deze naar behoren werkt, zal verder worden gegaan met de volgende feature. Derhalve hanteren wij een combinatie van de waterfall- en incremental methode. Het is de bedoeling dat het systeem binnen 10 weken gebouwd wordt. Wij zullen voornamelijk thuis werken en er zal via e-mail contact gehouden worden met dhr. Ronald Grahmbeek en Martin Kodde. Eens in de zoveel tijd is er een bijkomst tussen ons en dhr. Ronald Grahmbeek om details van het project te bespreken. Het systeem gaat er als volgt uitzien: Een MySQL database die gekoppeld is aan een Apache web server met PHP functionaliteiten. De servers zullen geleverd worden door Moerstaal.nl en zullen ook door hen beheerd worden. Wij krijgen ftp toegang op de webserver. Bachelor Project IN3700 - 5 -


Plan van Aanpak

1.3.3 Analyse + Ontwerp fase We gaan eerst goed in kaart brengen welke functionaliteiten de site moet hebben en aan de hand van deze functionaliteiten zullen we verschillende scenario’s ontwerpen. Deze scenario’s zullen we voorleggen aan de werkgever, zodat we zeker weten of de requirements van de werkgever ook overeenkomen met de requirements die wij in gedachte hebben. Als de requirements goed in kaart gebracht zijn, beginnen we met het ontwerpen van het systeem. Aangezien we gebruik gaan maken van object georiënteerde opties van PHP, zal er in het Object Design Document een klassendiagram komen. Ook zal daarin een ontwerp komen van de database. Er zullen geen sequence diagrammen gemaakt worden. Bijna alle communicatie verloopt tussen de site en de database. Als we van deze communicatie sequence diagrammen zouden maken, zou het weinig extra inzicht geven van het systeem. Daarbij zou het een soort herhalingsoefening worden. Tijdens de ontwerpfase zal er ook alvast nagedacht worden over testscripts die de functionaliteiten van het systeem testen, maar ook testscripts die de grenswaarden van het systeem opzoeken om te kijken of het systeem goed reageert. Verder zal er een overzicht worden gemaakt van welke schermen (GUI) er allemaal in het systeem moeten komen en hoe ze er globaal uit komen te zien.

1.3.4 Implementatie fase De taken worden tussen ons verdeeld aan de hand van bepaalde klassen of bepaalde functionaliteiten. Als een van ons tweeën iets verandert aan het ontwerp moet dit gelijk doorgevoerd worden in de documentatie. Als een stuk code af is, wordt de code gelijk gecompileerd en er wordt globaal gekeken of de functionaliteit klopt. Ook zal er steeds naar beveiliging gekeken worden. Zoveel mogelijk worden bepaalde security risico’s ontweken of er worden maatregelen daarvoor genomen (zie hoofdstuk 4). 1.3.5 Eind fase In deze fase zullen we alle testscripts loslaten op het systeem, zodat we kunnen controleren of het systeem aan de requirements voldoet. Als dat niet het geval is kunnen we eventuele fouten herstellen. Ook wordt het eindverslag afgemaakt en worden voorbereidingen getroffen voor de eindpresentatie.



Plan van Aanpak

1.4 Afspraken Op de website kunnen gebruikers vertrouwelijke informatie opslaan. Wij zijn mondeling overeengekomen met de heer Ronald Grahmbeek van Moerstaal.nl dat deze informatie niet aan derden zal worden doorverkocht of gegeven. Zij zullen alleen de NAW-gegevens gebruiken voor een nieuwsbrief en/of e-mailing.



Plan van Aanpak

Ook zijn we overeengekomen dat na acceptatie van de website door Moerstaal.nl, wij (Dennis de Bode en Roland Voets) vrijgesteld worden van elke verantwoordelijkheid met betrekking tot de website.

1.5 Leeswijzer In de volgende hoofdstukken worden de volgende zaken behandeld: • • • • •

In hoofdstuk 2 worden de requirements zoals vastgelegd in het RAD document besproken. In hoofdstuk 3 worden de security risico’s van de site besproken en onze maatregelen tegen deze risico’s. In hoofdstuk 4 wordt het ontwerp van het systeem besproken. In hoofdstuk 5 wordt besproken hoe we gaan testen en welke testen we gaan uitvoeren. In hoofdstuk 6 zullen we onze conclusies en onze aanbevelingen bespreken.

Sommige hoofdstukken zijn meer uitgebreid in aparte documentatie besproken. Deze documenten zijn als bijlagen aan dit document toegevoegd. • •

• •

Appendix A bevat de opdrachtomschrijving. Deze bevat de originele opdrachtomschrijving zoals die door Moerstaal.nl is aangeleverd. Appendix B bevat het Requirement Analysis Document. Daarin staan alle scenario’s beschreven en is er een overzicht van alle schermen van de website. Appendix C bevat het System Design Document. Daarin wordt het ontwerp van de website uitgelegd. Appendix D bevat het Testscripts Design Document. Daarin staan alle testscripts beschreven.



2

Requirements

Requirements

2.1 Introductie In het Requirements Analysis Document (RAD; zie Appendix B) worden de eisen (zowel functioneel als non-functioneel) gespecificeerd waaraan het systeem moet voldoen. Deze requirements worden ook in dit hoofdstuk besproken en we zullen als voorbeeld wat dieper ingaan op sommige punten. We onderscheiden de verschillende typen gebruikers van het systeem en beschrijven verschillende scenario’s die zich kunnen voordoen. Tevens worden alle schermen (GUI) gedefinieerd.

2.2 Functional requirements In het systeem onderscheiden we vier soorten gebruikers: • • • •

Niet-geregistreerde gebruikers Geregistreerde gebruikers Beheerders Superbeheerders

Niet-geregistreerde gebruiker is iedereen die op de website komt zonder een account te hebben. Deze gebruikers kunnen de startpagina benaderen en gegevens op deze pagina lezen. Deze informatie bestaat onder andere uit de voorwaarden die gelden wanneer men zich als gebruiker registreert bij NietVergeten.NL. Vanuit de startpagina kunnen ze het inlog gedeelte benaderen, dat een link bevat om zich te registreren op de website. Ook kunnen ze naar de contactpagina waar gegevens staan van de beheerders van de website. Geregistreerde gebruiker is iedereen die het systeem gebruikt om gegevens op te slaan met als doel deze niet meer te vergeten. Deze gegevens kunnen zijn: • • • •

Paspoortnummer Rijbewijsnummer Scans van documenten Data (verjaardagen, afloop abonnementen/verzekeringen)

Gebruikers kunnen reminders instellen voor bepaalde data. Zij kunnen opgeven hoeveel dagen voor een bepaalde datum een reminder moet worden verstuurd. Een reminder is een e-mail met daarin gegevens over het betreffende event (verjaardag, afloop abonnement/verzekering). Op elke pagina van het gebruikersgedeelte is er een navigatiebar te vinden, die ten allen tijde kan worden gebruikt om in- en uit te loggen. Indien een Bachelor Project IN3700 - 9 -


Requirements

gebruiker niet is ingelogd, is het label ‘Registreren’ beschikbaar voor het openen van de pagina registreren.php. Indien een gebruiker wel is ingelogd, verdwijnt het label ‘Registreren’ en verschijnen de labels ‘Overzicht’, ‘Account wijzigen’, ‘Documenten overzicht’, ‘Data overzicht’, ‘Document toevoegen’ en ‘Datum toevoegen’. Verder zijn de links ‘Home’, ‘Voorwaarden’ en ‘Contact’ altijd bereikbaar om resp. home.php, voorwaarden.php en contact.php te openen. Voor meer (visuele) informatie, zie sectie 3.5.2 van Appendix B. Beheerder is iedereen die in staat is gebruikers te beheren. Functies van een beheerder zijn: • • • • •

Blokkeren van gebruikers Verwijderen van gebruikers Selecteren van banners Geheime vragen toevoegen en verwijderen Categorieën toevoegen en verwijderen

Ook in het admin gedeelte van het systeem is een navigatiebar aanwezig, die op iedere pagina beschikbaar is. Het inloggen gaat bij de beheerders niet via de navigatiebar, maar via de beginpagina: login.php. Uitloggen gaat echter wel via een knop in de navigatiebar. De labels ‘Home’, ‘Zoek gebruiker’, ‘Geheime vragen’, ‘Categorieën’ en ‘Banners’ zijn altijd beschikbaar in de navigatiebar voor iedere beheerder. Voor meer (visuele) informatie, zie sectie 3.5.2 van Appendix B. Superbeheerder is iedereen die in staat is om gebruikers én beheerders te beheren. Functies van de superbeheerder: • • • • • • • • • •

(De)blokkeren van gebruikers Verwijderen van gebruikers Gegevens van gebruikers inzien Geheime vragen toevoegen en verwijderen Categorieën toevoegen en verwijderen Beheerders toevoegen Beheerders verwijderen Gegevens van beheerders inzien Uploaden van banners Export maken van alle data

Superbeheerders loggen in op hetzelfde admin gedeelte als de normale beheerders, maar hebben wat meer rechten. Het in- en uitloggen gaat op dezelfde manier. Naast de labels ‘Home’, ‘Zoek gebruiker’, ‘Geheime vragen’, ‘Categorieën’ en ‘Banners’, die altijd beschikbaar zijn in de navigatiebar voor iedere Bachelor Project IN3700 - 10 -


Requirements

beheerder, zijn er twee extra labels, namelijk ‘Beheerders’ en ‘Export data’. Voor meer (visuele) informatie, zie sectie 3.5.2 van Appendix B. 2.2

Nonfunctional requirements

Het belangrijkste is dat er gebruik wordt gemaakt van één van de servers van moerstaal. Op deze apache server zal PHP versie 4 worden geïnstalleerd. Deze is gekoppeld aan een SQL database, die staat op dezelfde server staat. Het is de bedoeling dat er zoveel mogelijk gebruik gemaakt moet worden van de OO functionaliteit van PHP. De pagina’s met waardevolle informatie zullen worden beveiligd middels 128 bits SSL encryptie. Voor alle nonfunctional requirements, zie appendix b, sectie 3.3.

2.3 2.3.1

Scenario’s Lijst Scenario’s

Wij hebben een aantal scenario’s gedefinieerd die naderhand zijn aangepast aan de hand van commentaar van de opdrachtgevers. Elk scenario heeft een gebruiker als actor, die staat tussen haakjes achter de naam van het scenario. Nu volgt een opsomming van deze scenario’s: Bezoeken van de site Registreren gebruiker Inloggen gebruiker Wachtwoord gebruiker vergeten Account gebruiker aanpassen Persoonsgegeven opslaan Persoonsgegeven inzien Datum opslaan Datum inzien Inloggen (super)beheerder Gebruiker blokkeren Gebruiker verwijderen Categorie toevoegen Categorie verwijderen Banner toevoegen Banner verwijderen Geheime vraag toevoegen Geheime vraag verwijderen Gegevens gebruiker inzien / wijzigen Beheerder verwijderen Beheerder toevoegen Export data

(Niet-geregistreerde gebruiker) (Niet-geregistreerde gebruiker) (Geregistreerde gebruiker) (Geregistreerde gebruiker) (Geregistreerde gebruiker) (Geregistreerde gebruiker) (Geregistreerde gebruiker) (Geregistreerde gebruiker) (Geregistreerde gebruiker) ((super)beheerder) ((super)beheerder) ((super)beheerder) ((super)beheerder) ((super)beheerder) ((super)beheerder) ((super)beheerder) ((super)beheerder) ((super)beheerder) (superbeheerder) (superbeheerder) (superbeheerder) (superbeheerder)



Requirements

Dit zijn de scenario’s voor de belangrijkste functionaliteiten van het systeem. Er zouden nog meer scenario’s bedacht kunnen worden, maar dat zijn scenario’s die vanzelfsprekend zijn en die automatisch bij de implementatie van de functionaliteiten van deze scenario’s meegenomen worden. Men moet hierbij denken aan scenario’s als bijvoorbeeld: Het foutief invoeren van een gebruikersnaam of het bezoeken van een pagina terwijl de gebruiker niet ingelogd is etc. De bovenstaande scenario’s zijn al in een algemene vorm gedefinieerd waardoor er per scenario meerdere situaties worden afgevangen. Eigenlijk zijn het daardoor niet echt scenario’s, maar combinaties van scenario’s en use cases (hieronder in sectie 2.3.2 nader te verklaren). Vandaar dat wij ervoor hebben gekozen om de use cases achterwege te laten. Deze zouden geen toegevoegde waarde hebben. In combinatie met de GUI + schermvolgorden (zie volgende sectie; 2.5) leveren de scenario’s een duidelijk beeld van de mogelijkheden van het systeem. Voor de uitwerkingen van alle bovenstaande scenario’s verwijs is naar appendix b, sectie 3.5.1. Wij zullen hier nu als voorbeeld het scenario registreren gebruiker bespreken. 2.3.2

Voorbeeld: Registreren gebruiker

Scenario naam: Actor: Flow of events:

Registreren gebruiker Piet: Niet-geregistreerde gebruiker 1. Piet surft via zijn webbrowser naar de site http://www.nietvergeten.nl. 2. Hij komt terecht op de pagina home.php. 3. In de navigatie bar aan de zijkant klikt hij op ‘schrijf je nu in’ en daardoor komt hij op de pagina registreren.php. 4. Hier staan verschillende input velden en een hyperlink naar voorwaarden.php. 5. Hij moet de volgende dingen opgegeven: 1. Gebruikersnaam 2. Wachtwoord (2 keer; het input veld is van het type hidden) 3. E-mail adres 4. Geheime vraag 5. Antwoord op geheime vraag 6. Of hij de nieuwsbrief wil ontvangen 7. Dat hij akkoord gaat met voorwaarden Als hij 1 van deze dingen niet opgeeft, kan hij niet geregistreerd worden als gebruiker van de website http://www.nietvergeten.nl. 6. De volgende dingen kan hij optioneel opgeven: 1. Naam 2. Adres 3. Postcode 4. Woonplaats Bachelor Project IN3700 - 12 -


Requirements

5. Land 6. Telefoon nummer Piet vult ze toch in. 7. Als Piet alles heeft ingevuld klikt hij op een button met het label ‘Registreer’. 8. Hij krijgt dan een confirmatie scherm dat aangeeft of de ingevulde informatie juist is (bijvoorbeeld de 2 ingevulde wachtwoorden matchen niet of de gebruikersnaam is al in gebruik). 9. Piet heeft alles goed ingevuld en krijgt de melding dat hij om de registratie te voltooien een e-mail moet openen die naar zijn opgegeven e-mailadres is gestuurd. Deze email bevat een link en als hij daarop klikt, wordt zijn account geactiveerd. Dit scenario geeft een duidelijke flow aan hoe een gebruiker zich moet aanmelden op de site. Ook is goed te zien dat het scenario in een algemene vorm beschreven staat. Er staat bijvoorbeeld bij punt 6: “kan hij optioneel opgeven” in plaats van bijvoorbeeld: “Piet geeft niks op” of “Piet geeft wel wat op”. Dit zouden dan weer 2 aparte scenario’s opleveren. Om de hoeveelheid aan (overbodige) scenario’s enigszins te beperken, hebben wij er dus voor gekozen om deze veralgemening van onze scenario’s te hanteren.

2.4 2.4.1

Schermen Lijst schermen + scenario’s

In de scenario’s staat ook duidelijk beschreven welke schermen de gebruiker te zien krijgt en in welke volgorde. In het RAD wordt deze volgorde van schermen getoond door middel van screenshots (zie appendix B, sectie 3.5.2). Nu geven we even kort een opsomming van welke schermen bij welk scenario horen en in welke volgorde. Bezoeken van de site (Niet-geregistreerde gebruiker) Home.php Registreren gebruiker (Niet-geregistreerde gebruiker) Home.php -> Registeren.php Inloggen gebruiker (Geregistreerde gebruiker) Home.php -> Overzicht.php Wachtwoord gebruiker vergeten (Geregistreerde gebruiker) Home.php -> Wachtwoordvergeten.php Account gebruiker aanpassen (Geregistreerde gebruiker) Overzicht.php -> Wijzigenaccount.php Bachelor Project IN3700 - 13 -


Requirements

Document opslaan (Geregistreerde gebruiker) Overzicht.php -> Toevoegenpg.php Document inzien (Geregistreerde gebruiker) Overzicht.php -> Overzichtpg.php -> Inzienpg.php Datum opslaan (Geregistreerde gebruiker) Overzicht.php -> Toevoegendatum.php Datum inzien (Geregistreerde gebruiker) Overzicht.php -> Overzichtdata.php -> Inziendatum.php Inloggen (super)beheerder ((super)beheerder) Login.php -> Beheer.php Gebruiker blokkeren ((super)beheerder) Beheer.php -> Gebruikers.php Gebruiker verwijderen ((super)beheerder) Beheer.php -> Gebruikers.php Categorie toevoegen ((super)beheerder) Beheer.php -> Overzichtcats.php Categorie verwijderen ((super)beheerder) Beheer.php -> Overzichtcats.php Banner toevoegen ((super)beheerder) Beheer.php -> overzichtbanners.php -> toevoegenbanner.php Banner verwijderen ((super)beheerder) Beheer.php -> overzichtbanners.php Geheime vraag toevoegen ((super)beheerder) Beheer.php -> Overzichtvragen.php Geheime vraag verwijderen ((super)beheerder) Beheer.php -> Overzichtvragen.php Gegevens gebruiker inzien / wijzigen (superbeheerder) Beheer.php -> Gebruikers.php -> Gebruikerwijzigen.php Beheerder verwijderen (superbeheerder) Beheer.php -> Beheerders.php Beheerder toevoegen (superbeheerder) Beheer.php -> Beheerders.php -> Toevoegenbeheerder.php Bachelor Project IN3700 - 14 -


Requirements

Export data (superbeheerder) Beheer.php -> Exportdata.php De screenshots geven een goed beeld van de manier waarop de functionaliteit die in de scenario’s besproken is in de praktijk in uitvoer gebracht kan worden. We geven weer als voorbeeld het registeren van een gebruiker. 2.4.2

Voorbeeld: Registreren Gebruiker

Registreren gebruiker:

->

home.php + registreren.php Bachelor Project IN3700 - 15 -


Requirements

Zoals te lezen is in het scenario kan de gebruiker zich registreren door aan de zijkant op de button met het label “Schrijf je nu in” te klikken. Hij komt dan op de pagina registreren.php terecht. De rest van stappen van het scenario zijn ook gemakkelijk af te lezen uit de screenshots. De gebruiker vult de velden in. De velden met een asterisk zijn verplicht en de velden zonder zijn optioneel. Als de gebruiker klaar is, klikt hij op de button met het label ‘Registreer’.



Security

3 Security 3.1

Inleiding

De “beveiliging” van een site is niet zomaar een requirement waar de site aan voldoet. De vraag of iets “veilig” is, is namelijk objectief. Het kan altijd meer of minder beveiligd worden. Het is wel iets waar zorgvuldig over nagedacht moet worden en vandaar dat hier een apart hoofdstuk aan gewijd is. We zullen in dit hoofdstuk verschillende mogelijke beveiligingsrisico’s identificeren en erbij uitleggen welke maatregelen we zelf hebben genomen. Hierbij moet een balans gevonden worden tussen “security” en “usability”.

3.2 3.2.1

Login gegevens Risico’s

De gebruiker heeft een gebruikersnaam en wachtwoord om op de site in te loggen en zo zijn gegevens te kunnen bekijken. De gebruiker kiest zelf zijn gebruikersnaam en wachtwoord. Het risico van het gebruik van de combinatie van gebruikersnaam en wachtwoord om in te loggen is dat als een derde persoon deze gegevens achterhaalt hij de gegevens van de betreffende persoon kan inzien. 3.2.2

Maatregelen

Bij het registreren wordt vereist dat de gebruiker een gebruikersnaam en wachtwoord kiest die minimaal 6 karakters zijn. Hierdoor kunnen derden de gebruikersnaam en wachtwoord niet gemakkelijk gokken. De gebruiker moet ook een geheime vraag en antwoord opgeven. Als de gebruiker zijn wachtwoord wil achterhalen, moet hij deze geheime vraag beantwoorden en wordt het wachtwoord naar zijn e-mail adres gemaild. Als de gebruiker zijn e-mail adres wil veranderen, moet hij in ieder geval altijd zijn wachtwoord opgeven. Er is besloten om geen gebruik te maken van cookies, zodat de gebruiker zich altijd moet inloggen om gebruik te maken van de site. Een cracker kan via een brute force aanval, de login gegevens van een user proberen te achterhalen. Een brute force aanval houdt in dat de cracker geautomatiseerd via een script de gebruikersnaam + wachtwoord probeert te gokken. Dit wordt tegen gegaan door de account van een gebruiker te blokkeren indien tien keer achter elkaar een foutief wachtwoord wordt opgegeven. Veel van deze maatregelen zijn nutteloos indien de user onzorgvuldig met zijn login gegevens omgaat. Hier is helaas weinig aan te doen. We kunnen de gebruiker alleen de juiste weg op helpen. Bachelor Project IN3700 - 17 -


3.3 3.3.1

Security

Communicatie tussen Gebruiker en server Risico’s

De communicatie tussen de server en gebruiker is een groot beveiligingsrisico. De communicatie tussen server en gebruiker gaat via het TCP/IP protocol en die is niet ontworpen voor veiligheid. Er zijn genoeg gaten voor crackers om te misbruiken. Een cracker kan via een sniffer (sniffers kunnen verkeer onderscheppen op digitale netwerken) bijvoorbeeld een gebruikersnaam en wachtwoord van een user onderscheppen. 3.3.2

Maatregelen

Dit kan verholpen worden door SSL of zoals het nu heet TSL. Bij SSL wordt er een verbinding opgezet tussen de server en gebruiker en alle data die daar overheen gaat wordt versleuteld. Wij hebben SSL geïnstalleerd op de webserver waarop nietvergeten.nl draait. Dit is zeer belangrijk daar gebruikers belangrijke, gevoelige informatie kunnen opslaan op de website. Het is uiteraard de bedoeling om het ‘kunnen onderscheppen’ van deze gegevens zoveel mogelijk te beperken.

3.4 3.4.1

Gebruik van globale variabelen Risico’s

Door het gebruik van globale variabelen die niet geïnitieerd worden op een php pagina zou een gebruiker via zijn browser de functionaliteit van de pagina kunnen beïnvloeden. Het volgende voorbeeld komt uit de php handleiding1. Stel men heeft de volgende code: 1

http://www.php.net/manual/en/ Bachelor Project IN3700 - 18 -


Security

Dan zou men via de browser door dit in te tikken in de adresbalk: http://www.examples.com/example.php?authorized=true gevoelige informatie kunnen bemachtigen. 3.4.2

Maatregelen

Het is zaak om ervoor te zorgen alle variabelen een initiële waarde krijgen of als dit niet kan, ervoor te zorgen dat het geen kwaad kan als de waarde wordt veranderd. Ook zullen veel globale variabelen zoals gebruikersnaam als session variabele gedefinieerd worden en die kunnen niet via de browser een waarde toegekend krijgen (tenminste als de sessions identifier onbekend is, zie volgende paragraaf).

3.5 3.5.1

Cross scripting / SQL Injection Risico’s

De site nietvergeten.nl heeft verschillende forms waar de gebruiker input kan achterlaten (om te registreren bijvoorbeeld). Alleen deze forms brengen een groot beveiligingsrisico met zich mee. De gebruiker kan potentiële kwaadaardige code achterlaten op de site of via de form schadelijke sql queries achterlaten. Een voorbeeld van Cross scripting is bijvoorbeeld bij het registreren in plaats van een gebruikersnaam iets op te geven in de trant van: “ ’ /> <script> kwaadaardige code ”. Deze code zou dan uitgevoerd kunnen worden op de site. Nog gevaarlijker is het als hij in plaats van een gebruikersnaam een sql querie achterlaat. Dit heet SQL injection. Dan zou de gebruiker informatie in de database kunnen aanpassen of verwijderen. 3.5.2

Maatregelen

Het is belangrijk om alle input te wantrouwen en eerst te filteren op html code en sql queries. Ook output moet gecontroleerd worden (dit heet escapen). Input en output worden door ons gefilterd/ge-escaped door gebruik te maken van de php klasse Validate2. Bij alle input wordt gechecked of het geen kwaadaardige code bevat. Een voorbeeld is als een gebruiker zich registreert, krijgt de variabele $_HTTP_POST_VAR['username'] een waarde toegekend. We maken dan een instantie aan van de klasse validate. Door de volgende code uit te voeren weten we zeker dat de input inderdaad een gebruikersnaam is: $username = $_HTTP_POST_VAR['username']; if( !$validate->string( $username, array('format'=>VALIDATE_ALPHA . VALIDATE_NUM .) ) ) 2

http://pear.php.net/package/Validate Bachelor Project IN3700 - 19 -


Security

De gebruikersnaam mag alleen uit letters en nummers bestaan die aan elkaar geschreven zijn.

3.6 3.6.1

Sessions Hijacking Risico’s

Op de site wordt elke user die is ingelogd, gekoppeld aan een session. Php genereert voor elke session een unieke ID. Deze worden bijgehouden in sessions files die worden opgeslagen in een gezamenlijke directory. De webserver van nietvergeten.nl draait meerdere websites. Als 1 van de sites gecracked wordt, kunnen de sessions files van alle andere websites ook bekeken worden. Ook wordt de session ID meegestuurd met elke pagina die de gebruiker opvraagt. Deze pagina kan dus onderschept worden en dus ook de session ID. Als iemand een session ID van iemand bemachtigd heeft, kan hij inloggen op de site zonder een gebruikersnaam of password op te geven. Hierbij moet gezegd worden, dat dit alleen mogelijk is als degene van wie de session ID is ook ingelogd is. 3.6.2

Maatregelen

Behalve de session ID zijn er meerdere methodes om een gebruiker te identificeren. Zo kan de site het ip adres van een user opvragen en ook welke browser hij gebruikt. Deze gegevens kunnen ook in de session opgeslagen worden: $_SESSION[‘ip’] = $_SERVER[‘REMOTE_ADR’]; $_SESSION[‘browser’] = $_SERVER[‘HTTP_USER_AGENT’]; Op elke pagina wordt gechecked of degene die ingelogd is dezelfde ip en browser heeft, die gekoppeld zijn aan de session. Als dit niet zo is, wordt hij automatisch uitgelogd. Het is heel sterk dat iemand tijdens het browsen opeens van browser en/of ip verandert.

3.7 3.7.1

Opslaan van scans op de ftp server Risico’s

Gebruikers kunnen scans uploaden naar de ftp server die ze later op de site kunnen bekijken. Deze scans worden in een directory opgeslagen, die bereikbaar is via de website. Hierdoor zouden gebruikers scans van andere gebruikers kunnen bekijken.


Technische Universiteit Delft 3.7.2

Security

Maatregelen

We hebben de bestandsnamen van de scans ge-encrypt met md5. Zo is het praktisch onmogelijk om de naam van een scan te gokken en die via een browser te bekijken. Ook is er geen index.html in de directory zodat mensen niet kunnen zien welke scans er allemaal in de directory staan. De beste oplossing voor dit probleem zou zijn om de directory met htaccess te beveiligen en de scans via een php script op te halen. Dit leverde alleen een paar usability issues op. Dan zouden gebruikers plaatjes van bepaalde types en plaatjes van meer dan 400 kb niet meer kunnen uploaden. Toen is in overleg met de mensen van Moerstaal voor bovenstaande oplossing gekozen; de encryptie van de bestandsnamen.

3.8

Conclusie

Zoals in de inleiding al vermeld is, kan er niet worden gezegd of de site “veilig” is. Er zijn maatregelen getroffen voor bepaalde beveiligingsrisico’s. Dit betekent echter niet dat de site compleet waterdicht is. Het kan altijd nog veiliger en er bestaan nog altijd andere beveiligingsrisico’s waar wij misschien nog niet eens van op de hoogte zijn. Het is straks de taak van de admins om dit nauwlettend in de gaten te houden en indien nodig het beveiligingsniveau omhoog te schroeven.



System Design

4 System Design 4.2

Introduction

In het System Design Document (SDD; zie Appendix C) wordt het (voorlopige) ontwerp van het systeem gegeven. Ook worden er algemene regels opgesteld die van kracht zijn tijdens het implementeren en geven we een overzicht van het systeem opgedeeld in subsystemen. Eerst zullen we de algemene regels doornemen. Dan volgt er een overzicht van de verschillende subsystemen met daarbij de verschillende functionaliteiten per subsysteem. Als laatste het ontwerp van de database en het klassendiagram.

4.3

Algemene regels

De programmeur moet zich tijdens het implementeren aan de volgende regels houden: • • • • • • • • 4.4

Hij voorziet zijn code van commentaar. Hij zorgt dat de lay-out van zijn code netjes is, zodat het goed leesbaar is. Veranderingen in het ontwerp moeten doorgevoerd worden in de documentatie. Grote teksten moeten in html files gezet worden. Hij zorg ervoor dat zijn code redundant is en fault tolerant. Hij test ook gelijk zijn eigen code. Input moet gefilterd worden en output ge-escaped (zie hoofdstuk 3). Globale variabelen moeten zoveel mogelijk een initiële waarde krijgen.

Subsystemen

Aan de hand van alle scenario’s en de schermvolgordes, hebben we het systeem in 3 subsystemen opgedeeld en de verschillende functionaliteiten die in de scenario’s besproken zijn onder verdeeld over de verschillende subsystemen. Er zijn 2 “functionaliteiten” hier aan toegevoegd. Dit zijn functionaliteiten van het systeem zelf en zijn daarom niet in de scenario’s gedefinieerd. Hier volgt een korte uitleg. De Database: Is een mysql database die verschillende gegevens bevat van het systeem (in de volgende paragraaf volgt een uitgebreid overzicht van de gegevens die de database bevat). Cronjobs: Cronjobs roepen om de zoveel tijd een php file aan. Zo kunnen automatisch de e-mails gegenereerd/verstuurd worden voor de triggers (die door de gebruikers ingesteld kunnen worden). Bachelor Project IN3700 - 22 -


4.4.1

System Design

Subsystemen + functionaliteiten

Frontend: Gedeelte van de site dat de niet-geregistreerde en geregistreerde gebruikers gebruiken. Is te bereiken via http://www.nietvergeten.nl/. Functionaliteiten: Registreren gebruiker Inloggen gebruiker Wachtwoord vergeten Account aanpassen Documenten opslaan Documenten inzien Data opslaan Data inzien Backend: Gedeelte van de site dat beheerders en superbeheerders gebruiken. Is te bereiken via http://www.nietvergeten.nl/admin. Functionaliteiten: Inloggen beheerder Wachtwoord vergeten Wachtwoord aanpassen Gebruiker blokkeren Gebruiker verwijderen Banner opslaan Banner wijzigen/verwijderen Geheime vraag toevoegen Geheime vraag verwijderen Categorie toevoegen Categorie verwijderen Gebruiker gegevens inzien Beheerder toevoegen Beheerder verwijderen Beheerder gegevens inzien Export data Server: De server waarop de site draait. Alleen de beheerders van de server kunnen hier instellingen wijzigen.



System Design

Functionaliteiten: Database Cronjobs Het frontend en het backend communiceren met de server door queries uit te voeren in de database. Ook informatie voor de cronjobs wordt eerst door het frontend in de database gezet. Php files lezen deze informatie weer uit de database en worden door de cronjobs om de zoveel tijd aangeroepen. Het frontend en backend communiceren niet direct met elkaar. Dit gebeurt via de database.


Technische Universiteit Delft 4.5

System Design

Database

4.5.1

Database model Gebruiker

Persoonsgegevens PK

PK

pgID

FK1

userID naam pg nummer startdatum einddatum notitie catID categorie

FK2

UserInfo

userID gebruikersnaam wachtwoord vraag antwoord emailadres nieuwsbrief geblokkeerd actief hash regdatum lastlogin foutelogin

Scans

PK,FK1

naam adres postcode plaats telnr land Data PK

datumID

FK1

userID naam datum tijd notitie triggerTijdstip triggerDatum triggerTijd catId categorie

Cats

PK

scanID

FK1 FK2

pgID userID naam notitie filenaam

PK

catID categorie type customLabel

Banners PK

bannerID

FK1

naam link page catID

FK2

Beheerder PK

beheerderID beheerdersnaam wachtwoord superbeheerder

userID

Vragen PK

vraagID vraag

Figure 2 Database ontwerp.

4.5.2

Toelichting

Alle wachtwoorden zullen met md5 encryptie in de database gezet worden. Alle ID attributen moeten incremental worden. Nu volgt er een korte toelichting op alle tabellen. Tabel gebruiker: bevat alle informatie die nodig is om te functioneren op de website. Bijna alle velden moeten een waarde hebben (op lastlogin na, die pas een waarde krijgt als de user voor het eerst inlogt).



System Design

Tabel UserInfo: bevat persoonlijke informatie over de user. De gebruiker is niet verplicht om deze informatie op te geven op de website. Dat is ook de reden dat deze velden niet in de tabel Gebruiker staan. Tabel Persoonsgegevens: bevat alle informatie met betrekking tot de documenten die de user op de website opslaat. De tabel bevat een veld catID en een veld categorie. De reden hiervoor is dat de user kan kiezen om een van de voor gedefinieerde categorieën te gebruiken of er zelf eentje aan te maken. Tabel Scans: bevat informatie over de scans die de user upload naar de site. Deze tabel bevat 2 foreign keys: userID en pgID. Dit is omdat een scan geupload kan worden en nog niet noodzakelijkerwijs al gekoppeld moet worden aan een persoonsgegeven. De user kan namelijk de scan na het uploaden gelijk weer verwijderen. In dat geval hoeft de scan dus niet gekoppeld te worden aan een persoonsgegeven. Tabel Data: bevat alle informatie met betrekking tot de Data die de Gebruiker opslaat op de site. Deze tabel bevat ook informatie over de triggers. Een gebruiker kan bij elke datum die hij opslaat ook een trigger opslaan. Op dat tijdstip krijgt hij een e-mail met daarin de gegevens van de opgeslagen datum. Tabel Cats: bevat alle informatie over de vooraf gedefinieerde categorieën (voor gebruik in Persoonsgegevens en Data). Tabel Banners: bevat alle informatie over de banners die op de site geplaatst worden. Hij bevat ook een link naar categorie. Op deze manier kan er bijv. een banner van een autoverzekering worden getoond indien een gebruiker de categorie ‘rijbewijs’ heeft gekozen. Tabel Beheerder: bevat alle informatie over de beheerders van de website. Het veld superbeheerder geeft aan of de beheerder meer rechten heeft dan normale beheerders. Tabel Vragen: bevat vooraf gedefinieerde geheime vragen die de user kan kiezen.


Technische Universiteit Delft 4.6 4.6.1

System Design

Object Georiënteerd Klassendiagram

Figure 3 Klassendiagram (voor een volledig klassendiagram zie appendix C sectie 5.1).

4.6.2

Toelichting

Dit klassendiagram bevat per klasse een selectief aantal functies om te laten zien hoe elke klasse ongeveer is ingedeeld. Deze functies geven een goed representatief beeld van het type functies dat in elke klasse is terug te vinden. We hebben er express voor gekozen niet direct het volledige klassendiagram (alle functies in elke klasse) weer te geven. Dit om de lezer niet te overspoelen met een waslijst aan functies. Het volledige klassendiagram incluis alle functies is terug te vinden in appendix C, sectie 5.1.



System Design

Omdat we gebruik maken van versie 4 van php kunnen klassen helaas niet van elkaar erven. Dit hebben we opgelost door database.php te includen in de klassen die eigenlijk van de klasse Database zouden moeten erven. Als dit systeem ooit geupgrade wordt naar php5, zou dit probleem verholpen kunnen worden. Waarom maken wij gebruik van de object georiënteerde functionaliteit van php? Door gebruik van klassen bevorderen we het hergebruik van code en gaan we overbodige code lines tegen. Dit kan ook door het includen van php files, maar als je gebruik maakt van de object georiënteerde functionaliteit van php, dan wordt een functie aangeroepen via een instantie van een klasse ($object->functie()). Nu weet je gelijk waar deze functie vandaan komt en krijg je meer inzicht in de functionaliteit. Anders zou je eerst alle geinclude php files moeten doorzoeken. De code wordt dus overzichtelijker. Klasse SiteFunctions: bevat alle functies die in elke pagina gebruikt kunnen worden. Het bevat veel functies voor het opbouwen van de site, maar ook functies voor bijvoorbeeld het versturen van e-mails. Klasse Imagefunctions: bevat alle functies die betrekking hebben op het uploaden van plaatjes naar de server. Gebruikers kunnen met behulp van deze klasse bijvoorbeeld scans van hun documenten uploaden. Klasse Sessions: regelt het sessie gebruik van de site. Door de functies van deze klasse kunnen de sessie variabelen een waarde toegekend krijgen. Hij gebruikt de klassen DbUser en DbAdmin om te kijken of de session variabelen een waarde moeten krijgen. Ook wordt in deze klasse gecontroleerd of er geen “sessions hijacking” plaatsvindt (zie paragraaf 3.7). Db Klassen: bevatten alle queries. Die kunnen via de functies van deze klassen aangeroepen worden. DbUser bevat alle queries die van toepassing zijn op de user van de website. DbAdmin bevat alle queries die van toepassing zijn op de admins van de website, maar ook queries die nodig zijn voor het beheren van de website. DbDocuments en DbData bevatten alle queries die nodig zijn voor de user om ofwel documenten ofwel data toe te voegen op de website en het beheren hiervan.



Test design

5 Test design

5.2

Introduction

In deze paragraaf zullen we uiteenzetten hoe er precies getest gaat worden. We zullen hier een samenvatting geven van welke testen we gaan doen en hoe de tests eruit gaan zien. Voor de volledige lijst van de testscripts verwijzen wij u naar het Testscripts Design Document (TDD; zie Appendix D).

5.3

Hoe gaan we testen?

We gaan zowel incremental testen; wat wil zeggen dat we tijdens de implementatie al gaan testen, als een eindtest houden. Bij incremental testen zal de programmeur als hij een stuk code/functionaliteit af heeft dit gelijk testen. Bij de eindtest worden alle functionaliteiten tegen het licht gehouden en wordt er een pilot test uitgevoerd. Bij functional testing en boundary testing zal er ook naar security gekeken worden.

5.4 5.4.1

Welke testen gaan we uitvoeren? Functional Testing:

Functional testing vindt het verschil tussen de requirements en het systeem. Via testscripts wordt gekeken of het systeem aan de functional requirements voldoet. Een testscript is niets meer dan een stappenplan van handelingen, dat een tester moet volgen om te kijken of het opgetreden gedrag overeenkomt met de requirements. Wij hebben de functional requirements beschreven aan de hand van scenario’s en schermvolgordes. Zoals eerder gezegd is bij de meeste van deze scenario’s / schermvolgordes het bedoelde gedrag erg duidelijk. Dus veel van het functionele testen zal zijn het volgen van deze scenario’s / schermvolgordes. Toch zullen er een paar testscripts daaraan toegevoegd worden, omdat de scenario’s niet alles afdekken. De volgende testscripts zijn toegevoegd: Testscripts: Gebruiker blokkeren -> inloggen gebruiker. Gebruiker blokkeren -> gebruiker is ingelogd. Geheime vraag verwijderen -> Opvragen wachtwoord. Categorie verwijderen -> Inzien persoonsgegeven. Login gebruiker -> niet ingelogd (security: zie paragraaf 3.2).



Test design

We zullen er 1 als voorbeeld uit pikken:

Voorbeeld: Gebruiker blokkeren -> inloggen gebruiker Testscript naam: Gebeurtenis: Gevolg:

Gebruiker blokkeren -> inloggen gebruiker. De beheerder blokkeert een gebruiker. Deze gebruiker probeert daarna in te loggen. Het systeem geeft de melding dat zijn account is geblokkeerd en dat hij contact moet zoeken met de beheerder. Hij kan niet inloggen.

Als je de scenario’s als testscripts gebruikt, wordt het blokkeren van een gebruiker getest en het inloggen van een gebruiker ook. Maar niet de combinatie van de twee. Daarom zijn er extra testscripts nodig.

5.4.2

Boundary Testing:

Op verschillende plaatsen op de website kunnen gebruikers gegevens invoeren. Bij Boundary testing kijk je of het systeem goed reageert bij het opgegeven van invoer die net op de grens is van het toelaatbare of daar overheen. Het is ook belangrijk dat het systeem herstelt van het geven van foutieve parameters en de user hiervan op de hoogte stelt. Men moet hier bijvoorbeeld denken aan het leeg laten van velden of geen geldige e-mail adres opgeven enz. Er zijn verschillende pagina’s op de website met een form waar de gebruiker gegevens kan invoeren. Deze pagina’s zijn: Home.php Registreer.php Wachtwoordvergeten.php Account.php Wijzigenemail.php Toevoegenpg.php Wijzigenpg.php Toevoegendata.php Wijzigendatum.php Op deze pagina’s moeten de volgende testscripts uitgevoerd worden: Testscript naam: Gebeurtenis:

Leeg laten velden. De gebruiker laat een veld leeg of laat verschillende velden leeg (de tester moet de verschillende combinaties nagaan) en drukt op de submit button.



Test design

Gevolg:

Het systeem moet een melding geven als het veld een waarde moet hebben en geen melding geven als het veld leeg gelaten mag worden.

Testscript naam: Gebeurtenis:

Invoeren foutieve gegevens. De gebruiker voert in 1 of meerdere velden foutieve gegevens in. Het systeem geeft een melding dat de user foutieve gegevens heeft ingevoerd.

Gevolg:

Testscript naam: Gebeurtenis: Gevolg:

Code injection (security: zie paragraaf 3.6). De gebruiker test of alle velden beveiligd zijn tegen code injection. Het systeem geeft een melding dat de user foutieve gegevens heeft ingevoerd.

Alle forms zijn natuurlijk niet hetzelfde. De forms hebben verschillende velden en sommige velden hebben wat extra aandacht nodig. Vandaar dat hieronder een paar testscripts zijn toegevoegd. Testscripts: Registreren gebruiker -> wachtwoord opgeven (security: zie paragraaf 3.2). Registreren gebruiker-> bestaande gebruikersnaam. Registreren gebruiker-> gebruiker gaat niet akkoord met voorwaarden. Registreren gebruiker-> 2 wachtwoorden komen niet overeen. De gebruiker heeft tijdens het registreren 2 verschillende wachtwoorden opgegeven. Login gebruiker-> geeft een verkeerd gebruikersnaam/wachtwoord op. Opslaan document-> upload een bestand dat geen image extensie heeft. Opslaan datum-> geen geldige datum. Opslaan datum-> verlopen datum. Opslaan datum-> trigger datum later dan datum. We halen weer één van deze testscripts eruit als voorbeeld: Voorbeeld: Registreren gebruiker-> bestaande gebruikersnaam Testscript naam: Pagina: Gebeurtenis: Gevolg:

Registreren gebruiker-> bestaande gebruikersnaam. Registreer.php De gebruiker gebruikt bij het registreren een gebruikersnaam die al bestaat. Het systeem geeft de melding dat deze gebruikersnaam al in gebruik is. De gebruiker wordt weer terug gestuurd naar het registratie form.



Test design

Niet op elk form hoeft gekeken worden of de gebruikersnaam al bestaat, maar op de pagina Registreer.php moet dit natuurlijk wel.

5.4.3

Pilot testing:

Pilot testing houdt in dat een groep gebruikers het systeem gaan gebruiken alsof het af is. Ze krijgen geen guidelines of scenario’s. Zo kunnen de gebruikers met een “frisse blik” naar het systeem kijken en feedback geven aan ons. Deze testfase begint ongeveer aan het einde van de implementatie, maar we moeten er wel op letten dat we nog tijd over hebben om de suggesties van de gebruikers te kunnen meenemen in het systeem. Functional testing en Boundary testing zullen incremental gebeuren tijdens de implementatie, maar ook in de eindfase zullen alle testscripts doorlopen worden.



Conclusies en Aanbevelingen

6 Conclusies en aanbevelingen

6.1

Inleiding

We zullen in dit hoofdstuk onze bevonden conclusies en de daarop volgende aanbevelingen uiteen zetten.

6.2 6.2.1

Aanpak Conclusies

We hebben ervoor gekozen om volgens de waterfall methode te werken maar tegelijkertijd bepaalde activiteiten, zoals het testen en het maken van het eindverslag, incremental te doen. Dit ging vrij goed. Sommige activiteiten volgen elkaar op en daarvoor is de waterfall methode handig. Daarnaast zijn er activiteiten die het gehele project doorlopen en van toepassing zijn op verschillende andere activiteiten. Als het RAD document gemaakt is, kan er een begin worden gemaakt met het SDD. Het is niet slim om dit tegelijk te doen, omdat er voor veranderingen in het RAD vaak ook veranderingen in het SSD nodig zijn. Het beste is dus om deze activiteiten volgens de waterfall methode uit te voeren. Bij testen is dit niet zo. Als er ergens bug gevonden is, kan deze bug misschien bij andere activiteiten ook verholpen worden en kan er in de toekomst op gelet worden dat deze fout niet meer gemaakt wordt. Derhalve kan testen het best incremental. Om deze combinatie van waterfall en incremental goed naar voren te laten komen in de planning is vrij lastig. We maakten gebruik van een ganttchart om onze planning weer te geven. De ganttchart is gemaakt voor de waterfall methode waardoor het niet goed mogelijk was om de ‘incremental activiteiten’ in de planning weer te geven. Activiteiten in een ganttchart moeten elkaar opvolgen en kunnen dus niet worden gesplitst. 6.2.2

Aanbevelingen

Het is voor elk project verschillend welke aanpak gebruikt moet worden, maar voor een soortgelijk project is het aan te raden om een combinatie van de waterfall methode en incremental methode te gebruiken. Voor het weergeven van de planning moet er een betere oplossing worden gevonden.



6.3 6.3.1


Analyse + ontwerp Conclusies

Bij de analyse en het ontwerp hebben we besloten dat we alleen algemene scenario’s zouden definiëren en geen sequence diagrammen en usecases zouden maken. In plaats daarvan hebben we per scenario aangegeven wat de schermvolgorde zou zijn. Een website is een gegevens-gedreven systeem en geen proces gedreven systeem. Een sequence diagram zou dus weinig extra informatie opleveren. Alle mogelijke scenario’s verzinnen en daaruit use cases te definiëren is niet zo zinvol. De functionaliteit van de website is vrij recht aan en veel functionaliteiten lijken op elkaar. Bijvoorbeeld om voor alle pagina’s apart een scenario te schrijven als “ indien een van de velden leeg wordt gelaten, geef dan een melding dat hij alsnog moet worden ingevuld” zou niet zo belangrijk zijn. Daarom hebben we in de scenario’s de functionaliteiten van de site algemeen beschreven. Men kan via de schermvolgorden een goed beeld krijgen van de manier waarop deze functionaliteiten op de website tot uiting komen. 6.3.2

Aanbevelingen

Als er in de toekomst uitbreidingen komen van de website is het aan te bevelen dat deze uitbreidingen ook in het RAD en SDD worden doorgevoerd. Men krijgt dan een goed beeld en overzicht van alle functionaliteiten van de website en onderlinge relaties tussen deze functionaliteiten.

6.4 6.4.1

Object georiënteerde functionaliteit van PHP Conclusies

Het gebruik van OO functionaliteit in php zorgt ervoor dat er meer structuur komt in de code en daarnaast wordt hergebruik van code bevorderd. De functies van een klasse kunnen in alle php files gebruikt worden en men weet precies waar deze functies staan, doordat functies worden aangeroepen gebruik makend van een instantie van de betreffende klasse. Door het gebruik van versie 4 van php was het niet mogelijk om alle functionaliteit van OO programmeren te gebruiken. Overerving is niet mogelijk evenals het gebruik van public en private variabelen/methoden. Ook is het niet mogelijk om in een klasse een andere klasse te gebruiken, maar het is maar de vraag of dat in versie 5 wel mogelijk is. 6.4.2

Aanbevelingen

Het is voor de site niet noodzakelijk om een hogere versie van php te installeren. Alleen om optimaal gebruik te maken van OO is het aan te raden om versie 5 van php te gaan gebruiken. Bachelor Project IN3700 - 34 -


6.5


Security

6.5.1 Conclusies Er zijn de nodige maatregelen genomen om de website te beveiligen, maar er kan niet gezegd worden of de site “veilig” is, omdat security niet zomaar een requirement is waar een website aan kan voldoen. Er moest ook een evenwicht tussen usability en security worden gevonden. Daardoor konden sommige security maatregelen niet worden doorgevoerd. Als we dit wel hadden gedaan, zou de gebruiksvriendelijkheid van de website afnemen.

6.5.2

Aanbevelingen

Wij hebben SSL op de webserver geïnstalleerd en adviseren iedereen om dit ook te doen bij het maken van websites die soortgelijke gevoelige gegevens gaan bevatten. Bij SSL wordt er als het ware een tunnel opgezet tussen de gebruiker en de webserver waar alle gegevens doorheen gaan. Die tunnel is zo afgesloten dat niemand anders erbij kan. Hierdoor kan geen gevoelige informatie worden onderschept. Eigenlijk is SSL bij websites zoals deze een must. Je moet er toch niet aan denken dat een kwaadwillende jouw paspoort- of verzekeringsgegevens onderschept en er mee aan de haal gaat. Om SSL te kunnen gebruiken, hebben wij zelf een zogenaamd testcertificaat + private key aangemaakt op de server. Het is aan te bevelen om een certificaat door een gespecialiseerd bedrijf als bijvoorbeeld Verisign of eTrust te laten maken, omdat hij dan door de web browser wordt gezien als ‘vertrouwd’. Zo’n testcertificaat wordt niet standaard door web browsers als ‘vertrouwd’ bestempeld, hetgeen zich openbaart in het feit dat bij contact met de website een bericht wordt getoond met daarin een melding die iets bevat als: “Het beveiligingscertificaat is uitgegeven door een bedrijf dat u niet als vertrouwd hebt aangemerkt”. Dit kan echter worden verholpen door het certificaat te installeren. Wij raden aan om dit niet te doen, tenzij het 100% zeker is dat het bedrijf dat het certificaat heeft uitgegeven te vertrouwen is. Het laten maken van een certificaat door een gespecialiseerd bedrijf kost zo’n 150 euro per jaar. Ook zou er gekeken kunnen worden of de problemen met het beveiligen van de scans directory d.m.v. htaccess opgelost kunnen worden. Voor de rest moeten de beheerders de “security” van de site in de gaten houden. Nieuwe lekken moeten worden opgespoord en zo snel mogelijk worden gedicht.



6.6 6.6.1


Testen Conclusies

Er is gebruik gemaakt van testscripts die handmatig door de tester gevolgd moeten worden. Dit is toch een effectieve manier om de “main” functionaliteit van de site te testen. Helaas laten de meeste geniepige bugs zich niet vinden door het volgen van testscript. Deze bugs komen hopelijk aan het licht bij de pilot test. Een systeem is nooit helemaal bug vrij. Er moet een balans worden gevonden tussen het verder testen van de site of het vrijgeven van de site (met de eventuele bugs). 6.6.2

Aanbevelingen

In de toekomst zou er gekeken kunnen worden naar geautomatiseerde tests in php, zogenaamde test robots.



7 Version list RAD [2.6] SDD [1.0] TDD [1.0] Database ontwerp nietvergeten.nl versie [1.0] Klassendiagram [0.7] Planning [0.3]


Version list


Appendix A

Appendix A: Opdracht omschrijving

Nietvergeten.nl Practicum opdracht voor Bachelor Eindpracticum opleiding Informatica, TU-Delft. Opdracht: Ontwikkel een website, inclusief beheeromgeving, voor de website nietvergeten.nl. Achtergrond Internet ontwikkeld zich steeds meer tot een medium dat overal en altijd aanwezig is, niet alleen via de vertrouwde pc, maar ook via mobiele netwerken en appartuur in huis. Het ontwikkelen van toepassingen voor allerdaags gebruik is daarom ook zinvol. Op Nietvergeten.nl moet een site ontstaan die, zoals de naam al zegt, een soort geheugensteun moet zijn. Op deze site kunnen gebruikers hun persoonlijke gegevens invoeren, samen met andere nuttige gegevens zoals paspoortnummer, rijbewijs, etc. Het inscannen en opslaan van belangrijke formulieren is ook mogelijk. Daarnaast kan men reminders instellen voor bepaalde gebeurtenissen. Moerstaal.nl is een product van Rede Consultancy B.V. Via Moerstaal.nl is het mogelijk om leuke Nederlandstalige e-mail- en homepage adressen aan te vragen. Hierbij levert Moerstaal extra diensten zoals een persoonlijke startpagina, het eenvoudig bouwen van homepages en kortingen op verschillende producten voor abonnees. Inmiddels kan men kiezen uit 2000 domeinnamen en heeft Moerstaal reeds meer dan 100.000 abonnees. Binnen het Moerstaal concept worden ook andere webdiensten ontwikkeld, zoals webactie.nl en tip100.nl. Hierbij wordt het grote potientieel aan abonnees binnen moerstaal gebruikt om nieuwe diensten te positioneren. Technische uitwerking Op dit moment is er nog geen start gemaakt met de ontwikkeling van de nietvergeten.nl website. Er zal dus een nieuwe website van de grond af gemaakt moeten worden. Hierbij moeten in ieder geval de volgende onderdelen aanwezig zijn: - Userinterface voor het inloggen, opvragen en invoeren van gegevens. - Beheerinterface voor het beheren van de gebruikers (blokkeren en verwijderen). Meerdere beheerders moeten kunnen inloggen op dit systeem. Enkele super-beheerders moeten de mogelijkheid hebben om de persoonsgegevens in te zien en een export te maken van deze gegevens. Er zal een keuze gemaakt moeten worden welke gegevens ten aller tijde afgeschermd blijven voor alle beheerders. - Modulaire opbouw, de site moet eenvoudig uit te breiden zijn, bijvoorbeeld met een SMSmodule of een wap-interface. - Beveiliging en encryptie van de gegevens. Verdere details over de uitwerking zullen in onderling overleg tijdens de opdracht worden besproken. De site moet worden gebouwd op één van de Moerstaal servers met behulp van PHP/MySQL. Moerstaal heeft op dit moment nog geen ervaring met de Object Oriented functionaliteit van PHP. Het heeft de voorkeur om deze website zo veel mogelijk OO te maken, waarna een uitspraak zou kunnen worden gedaan of de beheerbaarheid van websites door gebruik van deze techniek verbeterd. Organisatie Bachelor Project IN3700 - 38 -


Appendix A

Het project kan door één of twee studenten worden uitgevoerd. Hierbij wordt ervan uitgegaan dat er op basis van thuiswerken aan het project zal worden gewerkt. Er zijn twee begeleiders annex contactpersonen: Ronald Grahmbeek Engelshof 7 4021 VA Maurik 0344 693205 [email protected]

Martin Kodde Dunantstraat 330 2713 VG Zoetermeer 079 7112101 / 06 12111413 [email protected]

http://www.moerstaal.nl



Appendix B

Appendix B: Requirements Analysis Document

NietVergeten.NL

Requirements Analysis Document Roland Voets - 1058932 Dennis de Bode - 1027328



Appendix B

Index 1

INTRODUCTION ............................................................................................................................. 42

2

CURRENT SITUATION .................................................................................................................. 42

3

PROPOSED SYSTEM ...................................................................................................................... 42 3.1 OVERVIEW ................................................................................................................................... 42 3.2 FUNCTIONAL REQUIREMENTS ...................................................................................................... 42 3.3 NONFUNCTIONAL REQUIREMENTS ............................................................................................... 44 3.3.1 User interface and human factors .......................................................................................... 44 3.3.2 Documentatie.......................................................................................................................... 44 3.3.3 Hardware considerations ....................................................................................................... 44 3.3.4 Performance characteristics................................................................................................... 45 3.3.5 Error handling and extreme conditions.................................................................................. 45 3.3.6 System interfacing................................................................................................................... 45 3.3.7 Quality issues.......................................................................................................................... 45 3.3.8 System modifications .............................................................................................................. 45 3.3.9 Physical environment.............................................................................................................. 45 3.3.10 Security issues .................................................................................................................... 45 3.3.11 Resources and management issues..................................................................................... 45 3.4 CONSTRAINTS (“PSEUDO REQUIREMENTS”) ................................................................................. 46 3.5 SYSTEM MODELS.......................................................................................................................... 47 3.5.1 Scenarios ................................................................................................................................ 47 3.5.2 Scherm Volgorde .................................................................................................................... 56



1

Appendix B

Introduction

Het bedrijf Moerstaal.nl kwam met het idee om een website te ontwikkelen waarbij gebruikers belangrijke informatie kunnen opslaan, die zij later weer kunnen raadplegen. Deze website, genaamd NietVergeten.NL, dient derhalve als een geheugensteun. Dit document beschrijft de eisen waaraan de website moet voldoen. 2

Current situation

Moerstaal.nl is een product van Rede Consultancy B.V. Via Moerstaal.nl is het mogelijk om leuke Nederlandstalige e-mail- en homepage adressen aan te vragen. Hierbij levert Moerstaal extra diensten zoals een persoonlijke startpagina, het eenvoudig bouwen van homepages en kortingen op verschillende producten voor abonnees. Inmiddels kan men kiezen uit 2000 domeinnamen en heeft Moerstaal reeds meer dan 100.000 abonnees. Binnen het Moerstaal concept worden ook andere webdiensten ontwikkeld, zoals webactie.nl en tip100.nl. Hierbij wordt het grote potentieel aan abonnees binnen moerstaal gebruikt om nieuwe diensten te positioneren. Zo ook bij NietVergeten.NL, de website die van begin af aan zal worden opgebouwd en waarvan alle eisen in dit document zullen worden gespecificeerd. 3

Proposed system

3.1 Overview

Op de nieuwe website (hierna te noemen: systeem) moeten gebruikers kunnen inloggen waarna zij hun gegevens kunnen inzien en wijzigen. Deze gegevens kunnen variëren van polis- en rijbewijsnummers tot verjaardagen van vrienden. Ook moet het mogelijk zijn om scans van documenten te uploaden. Tevens moeten er een aantal beheerders zijn die in staat zijn om gebruikers te blokkeren en te verwijderen. Deze beheerders moeten net als de gebruikers kunnen inloggen door middel van een gebruikersnaam en wachtwoord. Tot slot is er een superbeheerder, die in staat is om beheerders toe te voegen c.q. te verwijderen. Deze superbeheerder heeft daarnaast de bevoegdheid om persoonlijke gegevens van gebruikers in te zien en zonodig aan te passen. Tevens moet een export van alle data kunnen worden gemaakt. 3.2 Functional requirements

We onderscheiden vier soorten gebruikers van het systeem: Bachelor Project IN3700 - 42 -


• • • •

Appendix B

Niet-geregistreerde gebruikers Geregistreerde gebruikers Beheerders Superbeheerders

Niet-geregistreerde gebruiker is iedereen die op de website komt zonder een account te hebben. Deze gebruikers kunnen de startpagina benaderen en gegevens op deze pagina lezen. Deze informatie bestaat onder andere uit de voorwaarden die gelden wanneer men zich als gebruiker registreert bij NietVergeten.NL. Vanuit de startpagina kunnen ze het inlog gedeelte benaderen, dat een link bevat om zich te registreren op de website. Ook kunnen ze naar de contactpagina waar gegevens staan van de beheerders van de website. Geregistreerde gebruiker is iedereen die het systeem gebruikt om gegevens op te slaan met als doel deze niet meer te vergeten. Deze gegevens kunnen zijn: • • • •

Paspoortnummer Rijbewijsnummer Scans van documenten Data (verjaardagen, afloop abonnementen/verzekeringen)

Gebruikers kunnen reminders instellen voor bepaalde data. Zij kunnen opgeven hoeveel dagen voor een bepaalde datum een reminder moet worden verstuurd. Een reminder is een e-mail met daarin gegevens over het betreffende event (verjaardag, afloop abonnement/verzekering). Op elke pagina van het gebruikersgedeelte is er een navigatiebar te vinden, die ten allen tijde kan worden gebruikt om in- en uit te loggen. Indien een gebruiker niet is ingelogd, is het label ‘Registreren’ beschikbaar voor het openen van de pagina registreren.php. Indien een gebruiker wel is ingelogd, verdwijnt het label ‘Registreren’ en verschijnen de labels ‘Overzicht’, ‘Account wijzigen’, ‘Overzicht persoonsgegevens’ en ‘Overzicht data’. Verder zijn de links ‘Home’, ‘Voorwaarden’ en ‘Contact’ altijd bereikbaar om resp. home.php, voorwaarden.php en contact.php te openen. Voor meer (visuele) informatie, zie sectie 3.5.2. Beheerder is iedereen die in staat is gebruikers te beheren. Functies van een beheerder zijn: • • • •

Blokkeren van gebruikers Verwijderen van gebruikers Uploaden van banners Geheime vragen toevoegen en verwijderen

Ook in het admin gedeelte van het systeem is een navigatiebar aanwezig, die op iedere pagina beschikbaar is. Het inloggen gaat bij de beheerders niet via de navigatiebar, maar via de beginpagina: login.php. Uitloggen gaat echter wel via een knop in de navigatiebar. Bachelor Project IN3700 - 43 -


Appendix B

De labels ‘Home’, ‘Zoek gebruiker’, ‘Geheime vragen’ en ‘Banners’ zijn altijd beschikbaar in de navigatiebar voor iedere beheerder. Voor meer (visuele) informatie, zie sectie 3.5.2. Superbeheerder is iedereen die in staat is om gebruikers én beheerders te beheren. Functies van de superbeheerder: • • • • • • • • • •

(De)blokkeren van gebruikers Verwijderen van gebruikers Gegevens van gebruikers inzien Geheime vragen toevoegen en verwijderen Beheerders toevoegen Beheerders verwijderen Gegevens van beheerders inzien Uploaden van banners Export maken van alle data Versturen van nieuwsbrief / e-mailing

Superbeheerders loggen in op hetzelfde admin gedeelte als de normale beheerders, maar hebben wat meer rechten. Het in- en uitloggen gaat op dezelfde manier. Naast de labels ‘Home’, ‘Zoek gebruiker’, ‘Geheime vragen’ en ‘Banners’, die altijd beschikbaar zijn in de navigatiebar voor iedere beheerder, zijn er twee extra labels, namelijk ‘Beheerders’ en ‘Export data’. Voor meer (visuele) informatie, zie sectie 3.5.2. 3.3 Nonfunctional requirements 3.3.1 User interface and human factors

Alle gebruikers zijn gewone mensen, zonder bijzondere vaardigheden op het gebied van computers en programmatuur. De gebruikersinterface moet voor hen intuïtief duidelijk zijn, zodat het zonder handleiding gebruikt kan worden. 3.3.2 Documentatie

Er hoeft geen gebruikershandleiding te worden geleverd. Wel dient de software van duidelijk commentaar te worden voorzien ten behoeve van het onderhoud. 3.3.3 Hardware considerations

Er wordt gebruik gemaakt van één van de servers van Moerstaal. Op deze server wordt PHP 4 geïnstalleerd. De server wordt gekoppeld aan een SQL database.



Appendix B

3.3.4 Performance characteristics

Moerstaal heeft op dit moment ruim 100.000 klanten. Indien NietVergeten.NL als dienst beschikbaar wordt voor alle bestaande gebruikers moet er dus rekening worden gehouden met het feit dat op bepaalde momenten honderden gebruikers tegelijkertijd actief zijn in het systeem. Dit mag echter niet als gevolg hebben dat gebruikers zoek- c.q. laadtijden ondervinden van meer dan 10 seconden per actie. Als iemand inlogt op het systeem of zijn gegevens wijzigt, mag dit derhalve niet langer dan 10 seconden in beslag nemen. 3.3.5 Error handling and extreme conditions

Een wijziging door een gebruiker of (super)beheerder wordt of geheel doorgevoerd, of niet doorgevoerd. Het systeem moet beveiligd zijn tegen totaal verlies van data. Er moet een voorziening zijn waarmee de superbeheerder een back-up kan maken en na calamiteiten de gegevens kan herstellen. 3.3.6 System interfacing

Het systeem hoeft niet met andere systemen samen te werken. 3.3.7 Quality issues

Er zal zoveel mogelijk gebruik worden gemaakt van de OO functionaliteit van PHP. Dit om het geheel overzichtelijker te maken en de uitbreidbaarheid te verbeteren. 3.3.8 System modifications

Het betreft een nieuw systeem, dus deze sectie is niet van toepassing. 3.3.9 Physical environment

Geen bijzondere eisen. 3.3.10 Security issues

Gebruikers kunnen alleen gegevens van zichzelf inzien en wijzigen. De superbeheerder van het systeem is de enige persoon die de bevoegdheid heeft om gegevens van alle gebruikers in te zien. Alle opgeslagen gegevens zullen worden beveiligd middels 128 bits SSL encryptie. 3.3.11 Resources and management issues

Niet van toepassing. Bachelor Project IN3700 - 45 -


Appendix B

3.4 Constraints (“pseudo requirements”)

Het systeem moet in PHP versie 4 worden geschreven. De gegevens moeten in een SQL database worden bewaard. Deze database wordt middels SQL queries benaderd.



Appendix B

3.5 System models 3.5.1 Scenarios Scenario naam: Actor: Flow of events:

Bezoeken van de site Piet: Niet-geregistreerde gebruiker 1. Piet surft via zijn webbrowser naar de site http://www.nietvergeten.nl. 2. Hij komt terecht op de pagina home.php. 3. Op deze pagina leest hij wat globaal de functionaliteiten zijn van deze site. 4. Hij kan verder naar de sites: registreren.php, voorwaarden.php en contact.php.


Registreren gebruiker Piet: Niet-geregistreerde gebruiker 1. Piet surft via zijn webbrowser naar de site http://www.nietvergeten.nl. 2. Hij komt terecht op de pagina home.php. 3. In de navigatie bar aan de zijkant klikt hij op ‘schrijf je nu in’ en daardoor komt hij op de pagina registreren.php. 4. Hier staan verschillende input velden en een hyperlink naar voorwaarden.php. 5. Hij moet de volgende dingen opgegeven: • Gebruikersnaam • Wachtwoord (2 keer; het input veld is van het type hidden) • E-mail adres • Geheime vraag • Antwoord op geheime vraag • Of hij de nieuwsbrief wil ontvangen • Dat hij akkoord gaat met voorwaarden Als hij 1 van deze dingen niet opgeeft, kan hij niet geregistreerd worden als gebruiker van de website http://www.nietvergeten.nl. 7. De volgende dingen kan hij optioneel opgeven: • Naam • Adres • Postcode • Woonplaats • Land • Telefoon nummer Piet vult ze toch in. 7. Als Piet alles heeft ingevuld klikt hij op een button met het label ‘Registreer’. 8. Hij krijgt dan een confirmatie scherm dat aangeeft of de ingevulde informatie juist is (bijvoorbeeld de 2 Bachelor Project IN3700 - 47 -


Appendix B

ingevulde wachtwoorden matchen niet of de gebruikersnaam is al in gebruik). 9. Piet heeft alles goed ingevuld en krijgt de melding dat hij om de registratie te voltooien een e-mail moet openen die naar zijn opgegeven e-mailadres is gestuurd. Deze email bevat een link en als hij daarop klikt, wordt zijn account geactiveerd. Scenario naam: Actor: Flow of events:

Inloggen gebruiker Piet: Geregistreerde gebruiker 1. Piet surft via z’n webbrowser naar de site http://www.nietvergeten.nl. 2. Hij komt terecht op de pagina home.php. 3. Aan de zijkant is er een apart frame waar Piet z’n gebruikersnaam en wachtwoord moet opgeven. Dit doet hij. 4. Als hij op OK heeft geklikt, komt hij terecht op de pagina overzicht.php.


Wachtwoord gebruiker vergeten Piet: Geregistreerde gebruiker 1. Piet surft via zijn webbrowser naar de site http://www.nietvergeten.nl. 2. Hij komt terecht op de pagina home.php. 3. Aan de zijkant is er een apart frame waar Piet z’n gebruikersnaam en wachtwoord moet opgeven. Dit doet hij. 4. Als hij op OK heeft geklikt, geeft de website de melding dat het wachtwoord niet klopt. 5. Piet is zijn wachtwoord vergeten. Op de pagina is er een label met de tekst “wachtwoord vergeten”. Piet klikt daarop. 6. Hij komt nu terecht op de site wachtwoordvergeten.php. 7. Op deze pagina verschijnt Piet zijn geheime vraag met een input veld waarin hij het antwoord moet opgeven. Dit doet hij. 8. Ook is er een veld waar hij z’n gebruikersnaam moet invullen. Als hij zijn gebruikersnaam opgeeft en op de OK button klikt, wordt er automatisch een e-mail verstuurd naar zijn e-mailadres met daarin zijn nieuwe wachtwoord.


Account gebruiker aanpassen Piet: Geregistreerde gebruiker 1. Piet is ingelogd op de website http://www.nietvergeten.nl. 2. In de navigatie bar is er een label met de tekst “account wijzigen”. Hij klikt daarop. Bachelor Project IN3700 - 48 -


Appendix B

3. Piet komt op de pagina wijzigenaccount.php terecht. 4. Hier staan alle inputvelden, met daarin de huidige gegevens van de gebruiker in het systeem. 5. Piet kan zijn gegevens veranderen door de inhoud van de inputvelden aan te passen. 6. Als hij zijn wachtwoord wil aanpassen, moet hij eerst zijn oude wachtwoord opgeven en vervolgens 2 maal zijn nieuwe wachtwoord. Deze velden zijn allemaal van het type hidden. 7. Piet vindt het eens tijd om z’n wachtwoord te vernieuwen en vult z’n oude wachtwoord in en daarna 2 keer zijn nieuwe wachtwoord. 8. Als Piet op de button ‘Wijzig’ drukt, worden de gegevens in de database aangepast. Scenario naam: Actor: Flow of events:

Document opslaan Piet: Geregistreerde gebruiker 1. Piet is ingelogd op de website http://www.nietvergeten.nl. 2. Op de pagina overzicht.php klikt hij op het label “Document toevoegen”. 3. Hij komt op de pagina toevoegenpg.php. 4. Hij selecteert uit de dropdown Paspoort” en vult alle velden in. 5. Bij het scan gedeelte kan hij via de browse button een scan die lokaal op z’n computer staat selecteren. Dit doet hij. 6. Hij vult in het invoerveld ‘naam scan’ de naam “scan paspoort” in en drukt daarna op de knop ‘upload’. 7. Hij slaat het document op via de button “Document opslaan”.


Document inzien Piet: Geregistreerde gebruiker 1. Piet is ingelogd op de website http://www.nietvergeten.nl. 2. Op de pagina overzicht.php klikt hij op het label “Documenten overzicht”. 3. Hij komt op de pagina overzichtpg.php. 4. Hier ziet hij een overzicht van alle persoonsgegevens die hij opgeslagen heeft. 5. Hij klikt op het label Paspoort. 6. Nu komt hij op de pagina inzienpg.php 7. Hier kan hij alle informatie over zijn paspoort die hij heeft opgeslagen bekijken.

Scenario naam:

Datum opslaan Bachelor Project IN3700 - 49 -


Appendix B

Actor: Flow of events:

Piet: Geregistreerde gebruiker 1. Piet is ingelogd op de website http://www.nietvergeten.nl. 2. Op de pagina overzicht.php klikt hij op het label “Datum toevoegen”. 3. Hij komt op de pagina toevoegendatum.php. 4. Hij vult bij naam “Verjaardag van Ria” in en geeft de datum 23-05-1969 op. Het veld ‘tijd’ laat hij leeg. 5. Hij vinkt de optie ‘herinnering’ aan en vult in het datum- en tijdveld van de trigger in dat hij op 09-052006 om 12:00 een herinnering wil ontvangen. 6. Hij klikt op de knop ‘Toevoegen’.


Datum inzien Piet: Geregistreerde gebruiker 1. Piet is ingelogd op de website http://www.nietvergeten.nl. 2. Op de pagina overzicht.php klikt hij op het label “Data overzicht”. 3. Hij komt op de pagina overzichtdata.php. 4. Hier ziet hij een overzicht van alle data die hij opgeslagen heeft. 5. Hij klikt op het label “Verjaardag van Ria”. 6. Nu komt hij op de pagina inziendata.php 7. Hier kan hij alle informatie over de verjaardag van Ria bekijken.


Inloggen (super)beheerder Martin: (super)beheerder 1. Martin surft via zijn webbrowser naar de site http://www.nietvergeten.nl/admin. 2. Hij komt terecht op de pagina login.php 3. Hij moet op deze pagina zijn gebruikersnaam en wachtwoord opgegeven. Deze vult hij in in de betreffende velden. 4. Als hij op ‘Log in’ heeft geklikt, komt hij terecht op de pagina beheer.php.

Scenario naam: Actors:

Gebruiker blokkeren Martin: (super)beheerder Piet: geregistreerde gebruiker 1. Martin is ingelogd op de website http://www.nietvergeten.nl/admin. 2. In de navigatie bar is er een label met de tekst “Zoek gebruiker”. Hij klikt daarop.

Flow of events:



Appendix B

3. Martin komt op de pagina wijzigengebruiker.php terecht. 4. Hij kan nu in een zoekveld een (gedeelte van een) gebruikersnaam invoeren en op de ‘zoek’ knop drukken. Hij vult alleen de ‘P’ in en drukt op de zoek button. 5. Alle gebruikersnamen die met een ‘P’ beginnen, verschijnen nu in een list. 6. Martin zoekt de gebruikersnaam van Piet in de tabel. 7. Als Martin op het label ‘blokkeer’ klikt, wordt de account van Piet geblokkeerd, wat wil zeggen dat hij niet meer in staat is om in te loggen. Scenario naam: Actors: Flow of events:

Gebruiker verwijderen Martin: (super)beheerder Piet: geregistreerde gebruiker 1. Martin is ingelogd op de website http://www.nietvergeten.nl/admin. 2. In de navigatie bar is er een label met de tekst “Zoek gebruiker”. Hij klikt daarop. 3. Martin komt op de pagina wijzigengebruiker.php terecht. 4. Hij kan nu in een zoekveld een (gedeelte van een) gebruikersnaam invoeren en op de ‘zoek’ knop drukken. Hij vult alleen de ‘P’ in en drukt op de zoek button. 5. Alle gebruikersnamen die met een ‘P’ beginnen, verschijnen nu in een list. 6. Martin zoekt de gebruikersnaam van Piet in de tabel. 7. Als Martin op het label ‘verwijder’ klikt, wordt de account van Piet verwijderd uit de database.


Categorie Toevoegen Martin: (super)beheerder 1. Martin is ingelogd op de website http://www.nietvergeten.nl/admin. 2. Op de pagina beheer.php klikt hij op het label “Categorieën”. 3. Hij komt op de pagina overzichtcats.php. 4. In het veld “naam categorie” moet hij de naam invullen van de categorie. Hij vult de naam “Verzekering” in. 5. Bij “label custom veld” vult hij de polisnummer in. 6. Daarna klikt hij op de radiobutton voor het label “doc” en drukt op de button “toevoegen” 7. Nu kan een geregistreerde gebruiker bij toevoegenpg.php de categorie “Verzekering” kiezen.

Scenario naam: Actor:

Categorie Verwijderen Martin: (super)beheerder Bachelor Project IN3700 - 51 -


Appendix B

Flow of events:

1. Martin is ingelogd op de website http://www.nietvergeten.nl/admin. 2. Op de pagina beheer.php klikt hij op het label “Categorieën”. 3. Hij komt op de pagina overzichtcats.php. 4. In de choicelist kiest hij de categorie die hij wil verwijderen. 5. Daarna drukt hij op de button “verwijder” 6. De categorie is dan verwijderd.


Banner Toevoegen Martin: (super)beheerder 1. Martin is ingelogd op de website http://www.nietvergeten.nl/admin. 2. Op de pagina beheer.php klikt hij op het label “Banners”. 3. Hij komt op de pagina overzichtbanners.php. 4. Hier krijgt hij een overzicht van banners die er zijn. 5. Hij klikt op de knop “Nieuw”. 6. Hij komt op de pagina toevoegenbanner.php. 7. Hij geeft de naam ‘ohra’ op. 7. Hij geeft via een hyperlink aan, waar de banner gevonden kan worden. 8. In de target link geeft hij aan waar de banner naar moet verwijzen. 9. Hij kan kiezen om de banner op een bepaalde pagina te laten verschijnen door het veld pagina in te vullen. 10. Martin kiest ervoor om bij het veld categorie te kiezen voor verzekering. Daardoor wordt de banner zichtbaar als een gebruiker de categorie verzekering kiest.


Banner Verwijderen Martin: (super)beheerder 1. Martin is ingelogd op de website http://www.nietvergeten.nl/admin. 2. Op de pagina beheer.php klikt hij op het label “Banners”. 3. Hij komt op de pagina overzichtbanners.php. 4. Hier krijgt hij een overzicht van banners die er zijn. 5. Hij drukt op het label “verwijderen” bij de banner die hij wil verwijderen.

Scenario naam: Actors: Flow of events:

Geheime vraag toevoegen Martin: (super)beheerder 1. Martin is ingelogd op de website http://www.nietvergeten.nl/admin. Bachelor Project IN3700 - 52 -


Appendix B

2. In de navigatie bar is er een label met de tekst “Geheime vragen”. Hij klikt daarop. 3. Martin komt op de pagina overzichtvragen.php terecht. 4. Hij vult in het veld de nieuwe vraag in. 5. Als Martin op de knop ‘Toevoegen’ drukt, wordt de nieuwe geheime vraag toegevoegd aan de database. Scenario naam: Actors: Flow of events:

Geheime vraag verwijderen Martin: (super)beheerder 1. Martin is ingelogd op de website http://www.nietvergeten.nl/admin. 2. In de navigatie bar is er een label met de tekst “Geheime vragen”. Hij klikt daarop. 3. Martin komt op de pagina overzichtvragen.php terecht. 4. Hij selecteert een bestaande vraag door middel van een dropdown list. 5. Als Martin op de knop ‘Verwijder’ drukt, wordt de geheime vraag verwijderd uit de database.

Scenario naam: Actors:

Gegevens gebruiker inzien / wijzigen Ronald: superbeheerder Piet: geregistreerde gebruiker 1. Ronald is ingelogd op de website http://www.nietvergeten.nl/admin. 2. In de navigatie bar is er een label met de tekst “Zoek gebruiker”. Hij klikt daarop. 3. Ronald komt op de pagina wijzigengebruiker.php terecht. 4. Hij kan nu in een zoekveld een (gedeelte van een) gebruikersnaam invoeren en op de ‘zoek’ knop drukken. Hij vult alleen de ‘P’ in en drukt op de zoek button. 5. Alle gebruikersnamen die met een ‘P’ beginnen, verschijnen nu in een list. 6. Ronald zoekt de gebruikersnaam van Piet (die toevallig ook met een P begint: Papua) in de tabel. 7. Als Ronald op het label ‘wijzig’ klikt, gaat hij naar de pagina wijzigengebruiker.php waar alle informatie van Piet (m.u.v. de persoonsgegevens en data) zichtbaar zijn en eventueel kunnen worden aangepast.

Flow of events:

Scenario naam: Actors: Flow of events:

Beheerder verwijderen Ronald: superbeheerder Martin: beheerder 1. Ronald is ingelogd op de website http://www.nietvergeten.nl/admin. 2. In de navigatie bar is er een label met de tekst “Beheerders”. Hij klikt daarop. 3. Ronald komt op de pagina beheerders.php terecht. Bachelor Project IN3700 - 53 -


Appendix B

4. Hij kan nu d.m.v. een dropdown list een beheerder selecteren aan de hand van zijn of haar gebruikersnaam. Hij selecteert Martin aan de hand van zijn gebruikersnaam ‘Gletsjer’. 5. Als Ronald op het label ‘verwijder’ klikt, wordt de account van Martin verwijderd uit de database. Scenario naam: Actors: Flow of events:

Beheerder toevoegen Ronald: superbeheerder Martin: beheerder 1. Ronald is ingelogd op de website http://www.nietvergeten.nl/admin. 2. In de navigatie bar is er een label met de tekst “Beheerders”. Hij klikt daarop. 3. Ronald komt op de pagina beheerders.php terecht. 4. Hij vult in het eerste veld de gebruikersnaam van Martin in en in het tweede veld een wachtwoord. 5. Als Ronald op de button ‘Toevoegen’ drukt, wordt de account van Martin toegevoegd aan de database.


Export data Ronald: superbeheerder 1. Ronald is ingelogd op de website http://www.nietvergeten.nl/admin. 2. In de navigatie bar is er een label met de tekst “export data”. Hij klikt daarop. 3. Ronald komt op de pagina exportdata.php terecht. 4. Hij geeft de naam van het bestand op en geeft aan in welk formaat het bestand moet zijn (txt, html of cvs). 5. Als Ronald op de button ‘exporteer’ drukt, worden de gegevens van alle gebruikers geëxporteerd in een bestand dat opgeslagen wordt op de webserver.

Scenario naam: Actor: Flow of Events

Versturen Nieuwsbrief Martin: (super)beheerder 1. Ronald is ingelogd op de website http://www.nietvergeten.nl/admin. 2. In de navigatie bar is er een label met de tekst “Nieuwsbrief/e-mailing”. Hij klikt daarop. 3. Ronald komt op de pagina nieuwsbrief.php terecht. 4. Hij tikt een bericht in de textarea en kiest de optie “nieuwsbrief”. 5. Dan klikt hij op de button “verstuur”. 6. Alle geregistreerde gebruikers die de optie “nieuwsbrief” aan hebben staan, krijgen de nieuwsbrief op de e-mail binnen.

Scenario naam:

Versturen E-mailing Bachelor Project IN3700 - 54 -

Technische Universiteit Delft Actor: Flow of Events

Appendix B

Martin: (super)beheerder 1. Ronald is ingelogd op de website http://www.nietvergeten.nl/admin. 2. In de navigatie bar is er een label met de tekst “Nieuwsbrief/e-mailing”. Hij klikt daarop. 3. Ronald komt op de pagina nieuwsbrief.php terecht. 4. Hij tikt een bericht in de textarea en kiest de optie “emailing”. 5. Dan klikt hij op de button “verstuur”. 6. Alle geregistreerde gebruikers krijgen de ingevulde tekst op de e-mail binnen.



Appendix B

3.5.2 Scherm Volgorde We laten voor elke scenario zien welke schermen de user voorgeschoteld krijgt. Bezoeken site:

home.php Userhandelingen: De gebruiker tikt http://www.nietvergeten.nl in in zijn adresbalk van zijn webbrowser. Hij komt dan terecht op home.php.



Appendix B

Contactgegevens bekijken:

->

home.php + contact.php Userhandelingen: De gebruiker klikt in home.php op het label ‘Contact’. Hij komt dan op contact.php terecht.



Appendix B

Registreren gebruiker:

->

home.php + registreren.php Userhandelingen: De gebruiker klikt in home.php op het label ‘Registreren’. Hij komt dan op registreren.php terecht. Daar vult hij alle velden in waarna hij drukt op de knop ‘registreer’.



Appendix B

Inloggen gebruiker:

->

home.php + overzicht.php Userhandelingen: De gebruiker voert zijn gebruikersnaam en wachtwoord in op de site home.php en drukt op de knop ‘Log in’. De ingevoerde gegevens worden gecontroleerd en als ze kloppen wordt de user doorgestuurd naar de site overzicht.php.



Appendix B

Wachtwoord gebruiker vergeten:

->

home.php + wachtwoordvergeten.php Userhandelingen: De gebruiker klikt in home.php op het label “wachtwoord vergeten”. Hij komt dan op wachtwoordvergeten.php terecht. Hij geeft daar zijn e-mail adres op en geeft daarna antwoord op zijn geheime vraag. Daarna klikt hij op de knop ‘OK’. Nu wordt er een mailtje gestuurd naar hem met zijn nieuwe wachtwoord.



Appendix B

Account gebruiker aanpassen:

->

overzicht.php + wijzigenaccount.php Userhandelingen: De gebruiker is ingelogd. Hij klikt op het label ‘account wijzigen’. Hij komt terecht op wijzigenaccount.php. Hij verandert hier de velden die hij wil wijzigen en drukt daarna op de button “Wijzig”.



Appendix B

Document inzien:

->

->



Appendix B

overzicht.php + overzichtpg.php + persoonsgegeven.php Userhandelingen: Gebruiker is ingelogd. Hij klikt op het label “Document overzicht”. Hij komt dan op de site overzichtpg.php terecht. Daar drukt hij op het op het document wat hij wil zien en dan wordt hij doorgestuurd naar persoonsgegeven.php.



Appendix B

Document opslaan:

->

overzicht.php + toevoegenpg.php Userhandelingen: Gebruiker is ingelogd. Hij drukt op het label “Document toevoegen”. Hij wordt doorgestuurd naar toevoegenpg.php. Als hij alle velden heeft ingevuld (scan is optioneel), drukt hij op de knop ‘Toevoegen’.



Appendix B

Document wijzigen:

->

->



Appendix B

overzicht.php + overzichtpg.php + wijzigenpg.php Userhandelingen: Gebruiker is ingelogd. Hij klikt op het label “Documenten overzicht” (of op de knop ‘Uitgebreid’ onder het veld met persoonsgegevens). Hij komt dan op de site overzichtpg.php terecht. Daar drukt hij op het label ‘wijzigen’ en dan wordt hij doorgestuurd naar wijzigenpg.php. Als hij alle velden heeft ingevuld (scan is optioneel), drukt hij op de knop ‘Document Wijzigen’.



Appendix B

Datum inzien:

->

->



Appendix B

home.php + overzichtdata.php + inziendatum.php Userhandelingen: Gebruiker is ingelogd. Hij klikt op het label “Overzicht data” (of op de knop ‘Uitgebreid’ onder het veld met data). Hij komt dan op de site overzichtdata.php terecht. Daar drukt hij op het label ‘toon’ en dan wordt hij doorgestuurd naar datum.php. Opmerking: de gebruiker had ook op de pagina overzicht.php op de knop ‘Toon’ kunnen drukken i.p.v. eerst naar de uitgebreidere tabel te gaan.


Technische Universiteit Delft Datum opslaan:


Appendix B


Appendix B

->

->



Appendix B

home.php + overzichtdata.php + toevoegendatum.php Userhandelingen: Gebruiker is ingelogd. Hij klikt op het label “Overzicht data” (of op de knop ‘Uitgebreid’ onder het veld met data). Hij komt dan op de site overzichtdata.php terecht. Daar drukt hij op de knop ‘Nieuw’ en dan wordt hij doorgestuurd naar toevoegendatum.php. Als hij alle velden heeft ingevuld, drukt hij op ‘Toevoegen’. Opmerking: de gebruiker had ook op de pagina overzicht.php op de knop ‘Nieuw’ kunnen drukken i.p.v. eerst naar de uitgebreidere tabel te gaan.



Appendix B

Datum wijzigen:

->

->



Appendix B

home.php + overzichtdata.php + wijzigendatum.php Userhandelingen: Gebruiker is ingelogd. Hij klikt op het label “Overzicht data” (of op de knop ‘Uitgebreid’ onder het veld met data). Hij komt dan op de site overzichtdata.php terecht. Daar drukt hij op het label ‘wijzig’ en dan wordt hij doorgestuurd naar wijzigendatum.php. Als hij alle velden heeft ingevuld, drukt hij op ‘Wijzigen’. Opmerking: de gebruiker had ook op de pagina overzicht.php op de knop ‘Wijzig’ kunnen drukken i.p.v. eerst naar de uitgebreidere tabel te gaan.



Appendix B

Inloggen beheerder:

->

login.php + beheer.php Userhandelingen: De beheerder surft naar http://www.nietvergeten.nl/admin. Hij komt dan automatisch op de login pagina. Nadat hij zijn gebruikersnaam en wachtwoord heeft opgegeven, wordt hij doorgestuurd naar beheer.php.



Appendix B

Gebruiker (de)blokkeren/verwijderen:

->

beheer.php + gebruikers.php Userhandelingen: Op de pagina beheer.php klikt de beheerder op het label ‘Zoek gebruiker’. Hij komt dan op de pagina gebruikers.php. Hij voert een gedeelte van / de gehele gebruikersnaam in van een bepaalde gebruiker. Nadat er op de knop ‘Zoek’ geklikt is, worden de betreffende gebruikersnamen getoond. Dan kan de beheerder via de labels ‘(de)blokkeer’ en ‘verwijder’ de gebruiker ofwel (de)blokkeren ofwel verwijderen.



Appendix B

Gebruiker wijzigen:

->

->



Appendix B

beheer.php + gebruikers.php + wijzigengebruiker.php Userhandelingen: Op de pagina beheer.php klikt de beheerder op het label ‘Zoek gebruiker’. Hij komt dan op de pagina gebruikers.php. Hij voert een gedeelte van / de gehele gebruikersnaam in van een bepaalde gebruiker. Nadat er op de knop ‘Zoek’ geklikt is, worden de betreffende gebruikersnamen getoond. Dan klikt de beheerder op het label ‘wijzig’ en komt hij op de pagina wijzigengebruiker.php. Daar is een overzicht van de gegevens van de gekozen gebruiker. Als de beheerder iets veranderd heeft, klikt hij op de knop ‘wijzig’ en de wijziging wordt in de database gezet.



Appendix B

Beheerder toevoegen:

->

->



Appendix B

beheer.php + beheerders.php + toevoegenbeheerder.php Userhandelingen: De beheerder klikt op de pagina beheer.php op het label ‘beheerders’. Hij komt dan terecht op de pagina beheerders.php. Daar klikt hij op de knop ‘nieuw’. Op de volgende pagina vult hij de velden in en klikt op ‘Toevoegen’.



Appendix B

Beheerder verwijderen:

->

beheer.php + beheerders.php Userhandelingen: De beheerder klikt op de pagina beheer.php op het label ‘beheerders’. Hij komt dan terecht op de pagina beheerders.php. Hij selecteert in de dropdown list de beheerder die hij wil verwijderen en klikt daarna op het label ‘verwijder’.



Appendix B

Beheerder wijzigen:

->

->



Appendix B

beheer.php + beheerders.php + wijzigenbeheerder.php Userhandelingen: De beheerder klikt op de pagina beheer.php op het label ‘beheerders’. Hij komt dan terecht op de pagina beheerders.php. Hij selecteert in de dropdown list de beheerder die hij wil wijzigen en klikt daarna op het label ‘wijzig’. Hij komt dan op wijzigenbeheerder.php terecht alwaar hij de gebruikersnaam en/of het wachtwoord van de betreffende beheerder kan wijzigen. Drukt hij daarna op ‘wijzigen’, dan worden de gegevens aangepast in de database. Export data:

->

beheer.php + exportdata.php Userhandelingen: De beheerder klikt op de pagina beheer.php op het label ‘Export data’. Hij komt dan terecht op de pagina exportdata.php. Daar geeft Bachelor Project IN3700 - 82 -


Appendix B

hij de locatie van het export bestand op (.txt) en drukt hij op de knop ‘Exporteer’. Categorie toevoegen:

->

Beheer.php + Overzichtcats.php Userhandelingen: De beheerder klikt op de pagina beheerder.php op het label ‘Categorieën’. Hij komt dan terecht op de pagina overzichtcats.php. Hij vult alles in en klikt op de button “Toevoegen”.



Appendix B

Categorie verwijderen:

->

Beheer.php + Overzichtcats.php Userhandelingen: De beheerder klikt op de pagina beheerder.php op het label ‘Categorieën’. Hij komt dan terecht op de pagina overzichtcats.php. Hij kiest de categorie die hij wil verwijderen en drukt daarna op de button “Verwijder”.



Appendix B

Banner uploaden:

->

->

beheer.php + overzichtbanners.php + toevoegenbanner.php Bachelor Project IN3700 - 85 -


Appendix B

Userhandelingen: De beheerder klikt op de pagina beheerder.php op het label ‘Banners’. Hij komt dan terecht op de pagina overzichtbanners.php. Daar drukt hij op de knop ‘nieuw’. Op de pagina toevoegenbanner.php vult hij alles in en drukt op de knop ‘toevoegen’.

Banner verwijderen:

->

beheer.php + overzichtbanners.php Userhandelingen: De beheerder klikt op de pagina beheerder.php op het label ‘Banners’. Hij komt dan terecht op de pagina overzichtbanners.php. Daar drukt hij op het label ‘verwijderen’ achter de naam van de banner die hij wil verwijderen.



Appendix B

Geheime vraag toevoegen:

->

beheer.php + overzichtvragen.php Userhandelingen: De beheerder klikt op de pagina beheerder.php op het label ‘Geheime vragen’. Hij komt dan terecht op de pagina overzichtvragen.php. Hij voert de nieuwe vraag in en drukt daarna op de knop ‘Toevoegen’.



Appendix B

Geheime vraag verwijderen:

->

beheer.php + overzichtvragen.php Userhandelingen: De beheerder klikt op de pagina beheerder.php op het label ‘Geheime vragen’. Hij komt dan terecht op de pagina overzichtvragen.php. In de dropdown list selecteert hij de vraag die hij wil verwijderen en drukt daarna op de knop ‘Verwijder’.



Appendix B

Versturen nieuwsbrief/e-mailing:

->

beheer.php + nieuwsbrief.php Userhandelingen: : De beheerder klikt op de pagina beheer.php op het label ‘Nieuwsbrief / E-mailing”. Hij komt dan terecht op de pagina nieuwsbrief.php. Hij vult zijn bericht in en kiest dan nieuwsbrief of e-mailing. Daarna drukt hij op de button “verstuur”.



Appendix C: System Design Document

NietVergeten.NL

System Design Document Roland Voets - 1058932 Dennis de Bode - 1027328


Appendix C


Appendix C

Index 1.

INTRODUCTIE................................................................................................................................. 92

2.

ALGEMEEN ...................................................................................................................................... 92

3.

FUNCTIONALITEITEN.................................................................................................................. 92 3.1 3.2

4.

92 93

DATABASE ....................................................................................................................................... 94 4.1 4.2

5.

SUBSYSTEMEN ............................................................................................................................. FUNCTIONALITEITEN PER SUBSYSTEEM ........................................................................................

DATABASE ONTWERP ................................................................................................................... 94 TOELICHTING ............................................................................................................................... 94

OBJECT GEORIËNTEERD............................................................................................................ 96 5.1 5.2

KLASSE DIAGRAM ........................................................................................................................ 96 TOELICHTING ............................................................................................................................... 97



Appendix C

1. Introductie Dit document gaat zich voornamelijk bezig houden met de design issues die voor de ontwikkelaars van toepassing zijn. Dit document moet een beeld geven van hoe het systeem ontworpen moet worden en hoe het technisch eruit komt te zien. Eerst zullen er een paar algemene regels voor de programmeur worden opgesomd die van toepassing zijn tijdens het ontwerpen van het systeem. Daarna zal er een ontwerp van de database gegeven worden en een klassendiagram.

2. Algemeen Het is van absoluut belang dat de programmeur “helder” programmeert. Hij voorziet zijn code van commentaar en zorgt er ook voor dat de lay-out van de code netjes is, zodat de code goed te lezen is. Als de programmeur van het ontwerp afwijkt, is dat niet erg, maar moet hij deze veranderingen wel doorvoeren in de documentatie. Dit zal de beheerbaarheid van de site erg ten goede komen. Grote teksten moeten in aparte html files gezet worden en ingevoegd (include) worden in de betreffende pagina’s. Ook moet de programmeur goed bedenken of zijn code redundant en fault-tolerent is. Errors moeten zoveel mogelijk worden afgevangen door error messages. Er moet aan de security gedacht worden. Input moet gefilterd worden en output ge-escaped worden. Globale variabelen moeten zoveel mogelijk een initiële waarde krijgen. Verder dient de programmeur zijn eigen code te compilen en ook gelijk te testen.

3. Functionaliteiten 3.1 subsystemen De website is op te delen in 3 subsystemen: •

Frontend

Gedeelte van de site dat de niet-geregistreerde en geregistreerde gebruikers gebruiken. Is te bereiken via http://www.nietvergeten.nl/. •

Backend

Gedeelte van de site dat beheerders en superbeheerders gebruiken. Is te bereiken via http://www.nietvergeten.nl/admin.



•

Appendix C

De server

De server waarop de site draait. Alleen de beheerders van de server kunnen hierop.

3.2 functionaliteiten per subsysteem Aan de hand van alle scenario’s en de schermvolgordes uit het RAD zijn de volgende functionaliteiten per subsysteem te onderscheiden: Subsysteem

Functionaliteit

Frontend Frontend Frontend Frontend Frontend Frontend

Registreren gebruiker Inloggen gebruiker Wachtwoord vergeten Account aanpassen Opslaan document Inzien/wijzigen/verwijderen document Opslaan/verwijderen scans Opslaan datum Inzien/wijzigen/verwijderen datum Inloggen beheerder Wachtwoord vergeten Wachtwoord aanpassen Gebruiker blokkeren Gebruiker verwijderen Banner opslaan Banner wijzigen/verwijderen Geheime vraag toevoegen Geheime vraag verwijderen Categorie toevoegen Categorie verwijderen Gebruiker gegevens inzien Beheerder toevoegen Beheerder verwijderen Nieuwsbrief versturen Beheerder gegevens inzien Export data Database Cronjobs

Frontend Frontend Frontend Backend Backend Backend Backend Backend Backend Backend Backend Backend Backend Backend Backend Backend Backend Backend Backend Backend Server Server

Impl. door: Dennis Dennis Dennis Dennis Roland Roland

Voltooid

Getest

X X X X X X

X X X X X X

Roland Roland Roland

X X X

X X X

Dennis n.v.t. Roland Roland Roland Roland Roland Roland Roland Roland Roland Roland Roland Roland Roland Roland Roland Dennis Beiden

X

X

X X X X X X X X X X X X X X X X X

X X X X X X X X X X X X X X X X X

Table 1 Overzicht functionaliteiten.



Appendix C

Deze tabel kan in de loop van de implementatie geupdate worden.

4. Database 4.1 Database ontwerp Gebruiker

Persoonsgegevens PK

PK

pgID

FK1

userID naam pg nummer startdatum einddatum notitie catID categorie

FK2

userID gebruikersnaam wachtwoord vraag antwoord emailadres nieuwsbrief geblokkeerd actief hash regdatum lastlogin foutelogin

Scans PK

scanID

FK1 FK2

pgID userID naam notitie filenaam

UserInfo PK,FK1

naam adres postcode plaats telnr land Data PK

datumID

FK1

userID naam datum tijd notitie triggerTijdstip triggerDatum triggerTijd catId categorie

Cats PK

catID categorie type customLabel

Banners PK

bannerID

FK1

naam link page catID

FK2

Beheerder PK

beheerderID beheerdersnaam wachtwoord superbeheerder

userID

Vragen PK

vraagID vraag

Figure 4 Database ontwerp

4.2 Toelichting Alle wachtwoorden zullen met md5 encryptie in de database gezet worden. Alle ID attributen moeten incremental worden. Nu volgt er een korte toelichting op alle tabellen.



Appendix C

Tabel gebruiker: bevat alle informatie die nodig is om te functioneren op de website. Bijna alle velden moeten een waarde hebben (op lastlogin na, die pas een waarde krijgt als de user voor het eerst inlogt). Tabel UserInfo: bevat persoonlijke informatie over de user. De gebruiker is niet verplicht om deze informatie op te geven op de website. Dat is ook de reden dat deze velden niet in de tabel Gebruiker staan. Tabel Persoonsgegevens: bevat alle informatie met betrekking tot de documenten die de user op de website opslaat. De tabel bevat een veld catID en een veld categorie. De reden hiervoor is dat de user kan kiezen om een van de voor gedefinieerde categorieën te gebruiken of er zelf eentje aan te maken. Tabel Scans: bevat informatie over de scans die de user upload naar de site. Deze tabel bevat 2 foreign keys: userID en pgID. Dit is omdat een scan geupload kan worden en nog niet noodzakelijkerwijs al gekoppeld moet worden aan een persoonsgegeven. De user kan namelijk de scan na het uploaden gelijk weer verwijderen. In dat geval hoeft de scan dus niet gekoppeld te worden aan een persoonsgegeven. Tabel Data: bevat alle informatie met betrekking tot de Data die de Gebruiker opslaat op de site. Deze tabel bevat ook informatie over de triggers. Een gebruiker kan bij elke datum die hij opslaat ook een trigger opslaan. Op dat tijdstip krijgt hij een e-mail met daarin de gegevens van de opgeslagen datum. Tabel Cats: bevat alle informatie over de vooraf gedefinieerde categorieën (voor gebruik in Persoonsgegevens en Data). Tabel Banners: bevat alle informatie over de banners die op de site geplaatst worden. Hij bevat ook een link naar categorie. Op deze manier kan er bijv. een banner van een autoverzekering worden getoond indien een gebruiker de categorie ‘rijbewijs’ heeft gekozen. Tabel Beheerder: bevat alle informatie over de beheerders van de website. Het veld superbeheerder geeft aan of de beheerder meer rechten heeft dan normale beheerders. Tabel Vragen: bevat vooraf gedefinieerde geheime vragen die de user kan kiezen.



5. Object georiënteerd 5.1 Klassendiagram

Figure 5 Klassendiagram


Appendix D


Appendix D

5.2 Toelichting Omdat we gebruik maken van versie 4 van php kunnen klassen helaas niet van elkaar erven. Dit hebben we opgelost door database.php te includen in de klassen die eigenlijk van de klasse Database zouden moeten erven. Als dit systeem ooit geupgrade wordt naar php5, zou dit probleem verholpen kunnen worden. Waarom maken wij gebruik van de object georiënteerde functionaliteit van php? Door gebruik van klassen bevorderen we het hergebruik van code en gaan we overbodige code lines tegen. Dit kan ook door het includen van php files, maar als je gebruik maakt van de object georiënteerde functionaliteit van php, dan wordt een functie aangeroepen via een instantie van een klasse ($object->functie()). Nu weet je gelijk waar deze functie vandaan komt en krijg je meer inzicht in de functionaliteit. Anders zou je eerst alle geinclude php files moeten doorzoeken. De code wordt dus overzichtelijker. Klasse SiteFunctions: bevat alle functies die in elke pagina gebruikt kunnen worden. Het bevat veel functies voor het opbouwen van de site, maar ook functies voor bijvoorbeeld het versturen van e-mails. Klasse Imagefunctions: bevat alle functies die betrekking hebben op het uploaden van plaatjes naar de server. Gebruikers kunnen met behulp van deze klasse bijvoorbeeld scans van hun documenten uploaden. Klasse Sessions: regelt het sessie gebruik van de site. Door de functies van deze klasse kunnen de sessie variabelen een waarde toegekend krijgen. Hij gebruikt de klassen DbUser en DbAdmin om te kijken of de session variabelen een waarde moeten krijgen. Ook wordt in deze klasse gecontroleerd of er geen “sessions hijacking” plaatsvindt. Db Klassen: bevatten alle queries. Die kunnen via de functies van deze klassen aangeroepen worden. DbUser bevat alle queries die van toepassing zijn op de user van de website. DbAdmin bevat alle queries die van toepassing zijn op de admins van de website, maar ook queries die nodig zijn voor het beheren van de website. DbDocuments en DbData bevatten alle queries die nodig zijn voor de user om ofwel documenten ofwel data toe te voegen op de website en het beheren hiervan.



Appendix D

Appendix D: Test Design Document

NietVergeten.NL

Testscripts Design Document Roland Voets - 1058932 Dennis de Bode - 1027328

“Software is written by humans and therefore has bugs.” -John Jacobs Bachelor Project IN3700 - 98 -


Appendix D

Index 1.

INLEIDING ..................................................................................................................................... 100 2.1 FUNCTIONAL TESTING................................................................................................................ 100 2.1.1 Functional testscripts ........................................................................................................... 100 2.1.2 Toevoegingen........................................................................................................................ 101 3.2 BOUNDARY TESTING .................................................................................................................. 102 3.2.1 Boundary testscripts ............................................................................................................. 102 3.2.2 Toevoegingen........................................................................................................................ 103



Appendix D

1. Inleiding In dit document zullen we een overzicht geven van alle testscripts die wij gedefinieerd hebben. De testscripts zijn opgedeeld in Functional testscripts en Boundary testscripts. Door de testscripts te doorlopen kun je zien of de functionaliteiten van het systeem overeenkomen met de requirements.

2.1

Functional testing

Wij hebben de functional requirements beschreven aan de hand van scenario’s en schermvolgordes. Zoals eerder gezegd is bij de meeste van deze scenario’s / schermvolgordes het bedoelde gedrag erg duidelijk. Dus veel van het functionele testen zal zijn het volgen van deze scenario’s / schermvolgordes. Een x aantal toevoegingen zullen het geheel afmaken.

2.1.1

Functional testscripts

De volgende functionaliteiten moeten getest worden: • • • • • • • • • • • • • • • • • • •

Bezoeken van de site Registreren gebruiker Inloggen gebruiker Wachtwoord gebruiker vergeten Account gebruiker aanpassen Persoonsgegeven opslaan Persoonsgegeven inzien Datum opslaan Datum inzien Inloggen (super)beheerder Gebruiker blokkeren Gebruiker verwijderen Banner uploaden Geheime vraag toevoegen Geheime vraag verwijderen Gegevens gebruiker inzien / wijzigen Beheerder verwijderen Beheerder toevoegen Export data

Deze kunnen getest worden door de scenario’s te volgen zoals ze gedefinieerd zijn in de RAD. Hier hoeven dus geen aparte testscript voor gemaakt te worden.



2.1.2

Appendix D

Toevoegingen

Sommige functionaliteiten hebben weer invloed op andere functionaliteiten. Daarom dat hieronder een paar testscripts zijn toegevoegd om deze situaties ook te testen. Testscript naam: Gebeurtenis: Gevolg:



Gevolg:


Gevolg:

Gebruiker blokkeren -> inloggen gebruiker. De beheerder blokkeert een gebruiker. Deze gebruiker probeert daarna in te loggen. Het systeem geeft de melding dat zijn account is geblokkeerd en dat hij contact moet zoeken met de beheerder. Hij kan niet inloggen. Gebruiker blokkeren -> gebruiker is ingelogd. De beheerder blokkeert een gebruiker. Deze gebruiker is al ingelogd en zit op de pagina overzichtpg.php. Als hij de pagina ververst of naar een andere pagina gaat voor ingelogde gebruikers, krijgt hij een melding dat zijn account is geblokkeerd. Hij wordt automatisch uitgelogd en wordt naar de homepagina doorverwezen. Geheime vraag verwijderen -> Opvragen wachtwoord. De beheerder verwijdert een geheime vraag. Een gebruiker die deze geheime vraag gebruikt, probeert z’n wachtwoord te achterhalen. De geheime vraag die verwijderd is, moet nog steeds zichtbaar zijn op de pagina wachtwoordvergeten.php. Alleen als gebruikers zich willen registreren op de site kunnen ze deze geheime vraag niet meer gebruiken. Categorie verwijderen -> Inzien persoonsgegeven. De beheerder verwijdert een categorie van het type doc. Een gebruiker die een persoonsgegeven van die categorie heeft, wil die persoonsgegeven bekijken via inzienpg.php. De categorie die verwijderd is, moet nog steeds zichtbaar zijn op de pagina inzienpg.php. Alleen als gebruikers een nieuwe persoonsgegeven toevoegen, moet die categorie niet meer gekozen kunnen worden.

Security: Testscript naam: Gebeurtenis:

Login gebruiker -> niet ingelogd. De gebruiker is niet ingelogd, maar surft wel direct naar de pagina overzicht.php (check ook alle andere pagina’s).


Technische Universiteit Delft Gevolg:

3.2

Appendix D

Het systeem laat de pagina niet zien, hij geeft wel een melding dat de gebruiker moet inloggen. Hij wordt doorverwezen naar de home pagina.

Boundary testing

Op verschillende plaatsen op de website kunnen gebruikers gegevens invoeren. Bij Boundary testing kijk je of het systeem goed reageert bij het opgegeven van invoer die net op de grens is van het toelaatbare of daar overheen. Het is ook belangrijk dat het systeem herstelt van het geven van foutieve parameters en de user hiervan op de hoogte stelt. Men moet hier bijvoorbeeld denken aan het leeg laten van velden of geen geldige e-mail adres opgeven enz.

3.2.1

Boundary testscripts

Er zijn verschillende pagina’s op de website met een form waar de gebruiker dingen kan invoeren. Deze pagina’s zijn: • • • • • • • • •

Home.php Registreer.php Wachtwoordvergeten.php Account.php Wijzigenemail.php Toevoegenpg.php Wijzigenpg.php Toevoegendata.php Wijzigendatum.php

Op deze pagina’s moeten de volgende testscripts uitgevoerd worden: Testscript naam: Gebeurtenis:

Gevolg:


Leeg laten velden. De gebruiker laat een veld leeg of laat verschillende velden leeg (de tester moet de verschillende combinaties) en drukt op de submit button. Het systeem moet een melding geven als het veld een waarde moet hebben en geen melding geven als het veld leeg mag gelaten worden. Invoeren foutieve gegevens. De gebruiker voert in 1 of meerdere velden foutieve gegevens in. Het systeem geeft een melding dat de user foutieve gegevens heeft ingevoerd.

Security:




3.2.2

Appendix D

Code injection. De gebruikers test of alle velden beveiligd zijn tegen code injection. Het systeem geeft een melding dat de user foutieve gegevens heeft ingevoerd.

Toevoegingen

Alle forms zijn natuurlijk niet hetzelfde. De forms hebben verschillende velden en sommige velden hebben wat extra aandacht nodig. Daarom dat hieronder een paar testscripts zijn toegevoegd.

Testscript naam: Pagina: Gebeurtenis: Gevolg:



Testscript naam: Pagina: Gebeurtenis:

Registreren gebruiker-> bestaande gebruikersnaam. Registreer.php De gebruiker gebruikt bij het registreren een gebruikersnaam die al bestaat. Het systeem geeft de melding dat deze gebruikersnaam al in gebruik is. De gebruiker wordt weer terug gestuurd naar het registratie form. Registreren gebruiker-> gebruiker gaat niet akkoord met de voorwaarden. Registreer.php De gebruiker geeft aan tijdens het registreren dat hij het niet eens is met de voorwaarden. Het systeem geeft de melding dat de gebruiker de voorwaarden moet accepteren om te kunnen registreren op deze site. De gebruiker wordt weer terug gestuurd naar het registratie form. Registreren gebruiker-> 2 wachtwoorden komen niet overeen. Registreer.php De gebruiker heeft tijdens het registreren 2 verschillende wachtwoorden opgegeven. Het systeem geeft de melding dat de 2 opgegeven wachtwoorden niet overeen komen. De gebruiker wordt weer terug gestuurd naar het registratie form. Login gebruiker-> geeft verkeerde gebruikersnaam/wachtwoord op. Navbar De gebruiker geeft tijdens het inloggen een verkeerde gebruikersnaam/wachtwoord op.



Appendix D

Gevolg:

Het systeem geeft de melding dat hij een verkeerde gebruikersnaam/wachtwoord heeft opgegeven. De gebruiker wordt weer terug gestuurd naar de pagina waar hij was.

Testscript naam:

Opslaan persoonsgegeven-> upload een bestand dat geen image extensie heeft. Toevoegenpg.php De gebruiker probeert een bestand te uploaden dat geen image extensie heeft. Het systeem geeft de melding dat hij een bestand probeert te uploaden dat niet ondersteund wordt. De gebruiker wordt weer terug gestuurd naar de pagina waar hij was.

Pagina: Gebeurtenis: Gevolg:




Opslaan datum-> Geen geldige datum. Toevoegendatum.php De gebruiker geeft bij de datum van de trigger een ongeldige datum (bijvoorbeeld 31-02-2006) op. Het systeem geeft de melding dat hij een ongeldige datum heeft opgegeven. De gebruiker wordt weer terug gestuurd naar de pagina waar hij was. Opslaan datum-> verlopen datum. Toevoegendatum.php De gebruiker bij de datum van de trigger een datum op die al verlopen is (bijv 01-01-1900). Het systeem geeft de melding dat hij een datum heeft opgegeven die al verlopen is. De gebruiker wordt weer terug gestuurd naar de pagina waar hij was. Opslaan datum-> trigger datum later dan datum. Toevoegendatum.php De gebruiker geeft bij de datum van de trigger een datum op die later is dan de datum van het item zelf. Het systeem geeft de melding dat de trigger datum later is dan de datum van de event zelf. De gebruiker wordt weer terug gestuurd naar de pagina waar hij was.

Security: Testscript naam: Gebeurtenis: Gevolg:

Registreren gebruiker -> wachtwoord opgeven. De gebruiker geeft bij het registreren een wachtwoord van 4 karakters op. Het systeem geeft een melding dat de wachtwoord te kort is.


NietVergeten.NL IN3700. Bachelor Project Roland Voets Dennis de Bode

Recommend Documents