Ontwerp
Je hebt vooraf nagedacht over technische keuzes en dit heb je inzichtelijk gemaakt. Je kan je project technisch documenteren middels minimaal twee diagrammen (bijv. ERD, klassendiagram en/of flow chart). Je hebt een bestaande library/API toegevoegd (server side) aan je project om functionaliteiten toe te voegen of om het programmeren makkelijker te maken. Je kunt toelichten waarom dit nuttig is.
Achtergrondinformatie:
Mijn opdrachtgever voor CLE2 was een garagehouder die graag wilde dat er online gereserveerd kon worden voor reparaties/keuringen bij zijn bedrijf. Daarnaast moest er ingelogd kunnen worden door werknemers zodat zij deze afspraken konden inzien, aanpassen en eventueel verwijderen. Ook moesten werknemers een account kunnen aanmaken om daarmee te kunnen inloggen.
Voorbereiding:
Allereerst ben ik begonnen met het opstellen van user stories, hierin wordt duidelijk gemaakt wat de belangrijkste functionaliteiten van het systeem moet worden. Deze functionaliteiten verdeel je onder 3 categorieën: must haves, could haves en should haves. Met dit block ga ik vooral inzoomen op de must haves, maar het is ook handig om te weten wat de extraatjes zijn in het systeem (could haves, should haves).
Bij mijn reserveringssysteem waren er een aantal dingen vereist door mijn opdrachtgever:
Als de reservering geplaatst wordt, moet deze de volgende gegevens bevatten van de klant: naam, email, telefoon. Van de afspraak zelf moeten deze gegevens te zien zijn: datum, tijd, de type afspraak (bijvoorbeeld een APK keuring of bandenvervanging). Als extra wilde mijn opdrachtgever ook nog een optie voor een leenauto, maar deze laat ik nu even buiten beschouwing aangezien dit geen prioriteit was om in het uiteindelijk systeem te komen (een should have).
Daarnaast moest het mogelijk zijn (bij het inlogsysteem) om voor de werknemers van het garagebedrijf te kunnen inloggen en de afspraken in te kunnen zien, aanpassen en verwijderen (zie de uitdaging “data” hiervoor.). Hiervoor moeten ze ook een account kunnen aanmaken op een registreer pagina.
ERD/flowchart:
Nadat deze prioriteiten duidelijk waren gemaakt, ben ik aan de slag gegaan met het maken van een ERD-diagram en een flowchart. Een ERD-diagram geeft de relaties tussen entiteiten (objecten) weer. Een flowchart is een visualisatie van hoe een proces verloopt.
ERD:
Zoals eerder genoemd zijn de entiteiten die bij het systeem horen: naam, email, telefoon, datum, tijd en type afspraak. Daarnaast heeft de admin ook een gebruikersnaam en wachtwoord. Dit heb ik allemaal verwerkt in de database en hier kwamen tabellen uit (die ik verderop in relatie met elkaar ga zetten -> ERD).
Deze 3 tabellen heb ik samengevoegd in een ERD-diagram, waarin de klant een één op veel relatie heeft met de afspraak (de klant kan meerdere afspraken maken, maar de afspraak kan maar één klant hebben). De admin heeft verder geen relatie met de klant of afspraak, maar het leek me wel goed om de admin als entiteit te benoemen, aangezien deze ook een rol speelt in het reserverings/inlogsysteem.
Flowchart:
In de flowchart wilde ik laten zien hoe het systeem in mijn hoofd zou moeten gaan werken. De bedoeling is om via de homepagina naar de reserveringspagina te gaan, om daar vervolgens een afspraak te kunnen maken, te kunnen inloggen via een “click me” link óf een account aan te kunnen maken als je die nog niet hebt. Hierna is het de bedoeling dat de juiste inloggegevens worden ingevoerd, anders wordt je teruggestuurd naar de inlogpagina. Als je ingelogd bent, kom je terecht op de “gemaakte afspraken pagina” en kun je kiezen om de afspraken aan te passen en/of te verwijderen (hierbij kom je ook weer op een aparte pagina terecht). Als je klaar bent, kun je uitloggen en kom je weer bij de inlogpagina terecht.
Het resultaat van de verschillende pagina’s zoals genoemd in de flowchart:
Library/API:
Een library is een code die al bestaat en ontwikkeld is, deze code voegt een bepaalde functionaliteit toe die vaker gebruikt kan worden in verschillende soorten projecten. Dit kan vaak handig zijn, want je hoeft niet de code helemaal opnieuw te schrijven van iets wat dan als geschreven is door iemand anders. Het enige wat je hoeft te doen is de code toe te passen in jouw eigen project.
Een API kun je zien als een soort “tussenpersoon/boodschapper. Een mooi voorbeeld wat dit duidelijk maakte vond ik op youtube (bron: https://www.youtube.com/watch?v=s7wmiS2mSXY ). Je zit in een restaurant en wilt iets van het menu bestellen, maar hoe komt dat bij de keuken terecht? Daar is de ober voor, de ober brengt jouw menukeuze naar de keuken en brengt vervolgens het gerecht van de keuken weer terug naar jou. De ober stelt in dit geval de API voor. In het geval van een computersysteem, kan een site zoals Trivago, de gegevens van alle hotelsites opvragen die hij dan met elkaar gaat vergelijken. Dit opvragen doet de API. In het kort, vraagt de API data/gegevens op, en brengt deze ook terug naar het gewenste systeem.
Ik heb uiteindelijk voor het gebruik van een library gekozen, de “Faker” library. Deze heeft als functie om neppe data te genereren. De data die je wil genereren kun je zelf kiezen, van namen tot emails. Ik heb als neppe data nodig: naam, email, telefoon, datum, tijd, type afspraak en leenauto (ja of nee). De code hieronder geeft dat weer:
Maar om gebruik te kunnen maken van deze library moest ik het eerst installeren dit heb ik m.b.v. een composer gedaan), en daarna met de require_once functie als het ware “activeren”. De database moet ook worden opgeroepen, anders wordt er niks opgeslagen.
Ik wilde deze library gebruiken om te kunnen testen of het afsprakensysteem zou werken, maar wel met neppe klanten. Door op de “klik hier” bij test te klikken, wordt de faker library gestart en komt er neppe data in de database te staan, maar wel met de gegevens die nodig zijn voor de afspraak bij de garage (naam,email, telefoon, datum, tijd, type afspraak en leenauto).
Dit is de github pagina die bij de Faker library hoort:
https://github.com/fzaninotto/Faker
Data
Je hebt een webapplicatie gebouwd op de server die gevoed wordt door een database. De database inhoud kan gelezen, bewerkt en verwijderd worden.
Eerst laat ik in het filmpje zien hoe ik (door eerst in te loggen) de afspraken kan zien, vervolgens bewerk en daarna ook verwijder.
Als allereerst moet er een connectie komen met de database. Dit heb ik gedaan d.m.v. de file database.php aan te maken. De “mysqli_connect” functie zorgt er uiteindelijk voor dat de connectie gemaakt wordt bij een success (en geeft een error wanneer het false is). De naam van mijn database is database1 zoals aangegeven staat op de 3e regel.
De “delete code” die hieronder staat weergegeven zorgt ervoor dat de afspraak verwijderd kan worden. Bovenaan moet er wel eerst voor gezorgd worden dat de database.php file included wordt zodat je deze niet helemaal opnieuw hoeft uit te typen. Daarna wordt gecheckt of de $_POST[“submit”] geset is of niet. Hierna komt een query waar wordt geselecteerd uit de tabel “gebruikers” waar “id” = mysqli_escape_string($db, $_GET[‘id’]);. De mysql_escape_string functie zorgt ervoor dat er een string veilig kan worden ingevoerd in de database.
Hierna komt het stukje “delete data”. Hieruit wordt een query gemaakt die dus de gehele “id” verwijderd uit de tabel “gebruikers”. Hierna wordt de connectie afgesloten en wordt je na het verwijderen van de “id” teruggestuurd naar de pagina “tabel.php” (zie filmpje hiervoor ook).
Als er geen resultaat terugkomt (id was niet aanwezig) of er de form was niet verzonden, dan wordt je ook teruggestuurd naar de “tabel.php” pagina.
Hieronder is de html code, waarin je op een aparte pagina komt wanneer je de afspraak wilt verwijderen. De vraag wordt nog gesteld of je zeker weet of je de afspraak wilt verwijderen, waarop je de keuze hebt om op de knop terug te klikken of op de verwijderen knop te klikken. In beide gevallen wordt je teruggestuurd naar tabel.php, alleen bij de knop verwijderen wordt het stukje “DELETE DATA” in actie gezet, terwijl bij het knopje terug de afspraak blijft staan.
Net zoals bij de delete pagina wordt bij de edit pagina ook de database.php file included. Daarna wordt de $_POST [“submit”] weer gecontroleerd of die geset is, anders gebeurt er niks. Daarna heb ik de variabelen opgeslagen in de array en vervolgens de query uitgeschreven. Bij de edit functie hoort de “update” query, dus ik wilde de tabel “gebruikers” updaten waarbij de datum en tijd geset zouden worden naar $datum en $tijd. De voorwaarde was dan dat id=$id moest zijn.
Als er een resultaat kwam, moest je terugverwezen worden naar de pagina “tabel.php” en bij een error moest de tekst “Something went wrong in your database query” getoond worden. Het stuk wat hierna komt is vrijwel identiek aan het stukje code dat ook in de delete pagina stond (het sluiten van de connectie en doorsturen naar de tabel.php pagina, etc.)
Het html stukje hieronder weergeeft dat je met pijltjes (input id= datum en input type=time) de cijfers kan veranderen. Mijn opdrachtgever wou dat de tijd niet verder kon dan 17:00 uur en vroeger dan 08:00 uur, en het in sprongen van een half uur moest. (min, max en steps in sec). Wanneer de datum en tijd gezet was naar wat de persoon wilt, dan kon je met de knop “opslaan” de afspraak definitief wijzigen en wordt je teruggestuurd naar de tabel.php pagina. Als je de afspraak toch niet wilt wijzigen, is er nog altijd weer de “terug” knop.
Beveiliging
Een deel van je website is niet toegankelijk zonder in te loggen. Je form invoer wordt op de server gevalideerd en is beveiligd tegen xss en sql injecties. Wachtwoorden worden veilig opgeslagen.
Het is de bedoeling dat de werknemers kunnen inloggen wanneer zij een account hebben aangemaakt.
Met het filmpje laat ik eerst zien hoe je een account aanmaakt, en daarna de tabel.php pagina (gemaakte afspraken) niet kan zien zonder eerst in te loggen. Als je niks invult in de velden, krijg je een foutmelding en kun je niet inloggen, dit geldt ook wanneer het wachtwoord en/of gebruikersnaam niet klopt. Wanneer je wel de juiste gebruikersnaam en wachtwoord hebt ingevoerd, wordt je doorgestuurd naar de tabel.php pagina. Wat ik hierna op het filmpje doe, is de pagina wegklikken om vervolgens weer in de zoekbalk de tabel.php pagina te openen. Wat eerst niet lukte, lukte nu wel. Als je ingelogd bent, blijft die sessie bestaan en blijf je toegang krijgen tot de tabel pagina. Pas als je op de tabel pagina op “uitloggen” klikt, wordt de sessie beëindigd en kun je niet meer bij de tabel pagina, tenzij je weer inlogt.
Hashen wachtwoorden:
Bij het aanmaken van een account heb ik gebruik gemaakt van wachtwoorden hashen. Dit zorgt ervoor dat een wachtwoord beveiligd wordt en niet herkenbaar is. In de foto hieronder is dat goed te zien.
Hieronder staat ook nog de code van het aanmaken van een account, met de nadruk op het hashen van de wachtwoorden
Bij het inloggen moet het omgekeerde gebeuren. Het systeem moet controleren dat het normaal getypte wachtwoord van de gebruiker overeenkomt met het gehashte wachtwoord (met password_verify). De code hieronder geeft dat weer.
Wat er samengevat gebeurt door de bovenstaande code:
- je kan een account aanmaken door een gebruikersnaam en wachtwoord te verzinnen.
- komt een foutmelding wanneer één of meerdere velden niet zijn ingevuld.
- nadat er een account is aangemaakt, is je wachtwoord in de database gehasht.
- wanneer je wilt inloggen, dien je de juiste gebruikersnaam en wachtwoord in te vullen die je zelf hebt aangemaakt, anders komt er een foutmelding.
- er komt ook weer een foutmelding wanneer één of meerdere velden niet zijn ingevuld.
- de password_verify() functie zorgt ervoor dat het gehashte wachtwoord gecontroleerd wordt bij inloggen (of die overeenkomt met het “normale” wachtwoord).
- als dit allemaal gelukt is, kom je bij de tabel.php pagina terecht.
XSS beveiliging:
Xss staat voor cross-site scripting. Dit is een fout in de beveiliging (bug) die wordt veroorzaakt doordat de invoer (cookie, request) die de website ontvangt, niet juist wordt verwerkt. Hierdoor kunnen hackers code injecteren, waardoor sessies van de gebruiker kunnen worden bekeken of zelfs kunnen worden overgenomen. Wat is de oplossing tegen deze xss injecties? Als voorbeeld hieronder heb ik een form opgesteld waarbij je je naam en leeftijd moet invullen.
De code ziet er goed uit, behalve dat op regel 18 en 19 de post-waarde van naam en leeftijd getoond wordt op het scherm. Dus stel je typt bij naam Jan/> in, dan plaatst PHP dat tussen de value tags en komt het in je broncode te staan. Dit willen we natuurlijk niet. Oplossing hiervoor (en dus ook tegen xss injecties) zijn htmlspecialchars. Deze zet vreemde tekens om in tekens die dan ongevaarlijk worden voor de broncode. De code hieronder zet m.b.v. de htmlspecialchars nu de ingevulde naam Jan/> om naar een ongevaarlijke output: Jan\” />. Door deze htmlspecialchars te gebruiken, kan er geen misbruik meer worden gemaakt van je code d.m.v. xss injecties.
