Back-end Block
De back-end is het hart van je web-applicatie. De server verwerkt en bewaart alle informatie op één plek, waardoor meerdere clients van dezelfde data gebruik kunnen maken. De applicatie biedt de mogelijkheid tot het beheren van de content met een CMS.
Informatie moet op een veilige manier opgeslagen worden en toegankelijk zijn. Onderdelen als authenticatie en autorisatie, hashing en controle van de data zijn enkele voorbeelden.
Deze basis moet stabiel en robuust zijn, daarom willen we er zo min mogelijk aan veranderen. Bij het uitwerken van de code is het belangrijk dat er nagedacht wordt over de kwaliteit van de code. Het moet voor een programmeur niet te veel tijd kosten om onderdelen toe te voegen of aanpassingen te doen zonder het systeem helemaal aan te passen.
Om tot deze kwaliteit te komen is het belangrijk om een ontwerp te maken waarbij functionaliteiten omgezet worden naar technische uitwerkingen. Hoofdonderdelen worden beschreven, de werking van taken wordt technisch toegelicht en ingewikkelde taken worden onderzocht. De keuze voor de uitwerking wordt verantwoord.
Bij het opzetten van de backend kan gebruik gemaakt worden van onderdelen die al bestaan. Denk aan een bestaande library met tools die te specialistisch zijn om zelf te bouwen of het gebruik van een webservice.
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.
Dit is mijn eerste project waarbij back-end echt een grote rol speelt. Vooraf heb ik nagedacht over welke talen ik wilde gebruiken. Uiteraard heb ik voor het verwerken van gevoelige data PHP gebruikt omdat deze data op de server blijft en niet inzichtelijk is voor gebruikers. Ook werk ik met een MySQLi database om deze data op te slaan. Al snel werd duidelijk dat de opdrachtgever ook een log-in-systeem wilde waarmee gebruikers vaker afspraken kunnen inplannen. Hiervoor is het wel nodig om wachtwoorden op te slaan. Dit heb ik gedaan door gebruik te maken van de password hash functie welke in PHP zit. Met deze hash kan ik de wachtwoorden veilig in de database bewaren.
Ik heb nog niet eerder een flow chart gemaakt maar hieronder heb ik er een geplaatst welke overeen komt met de website. Mochten er dingen onduidelijk zijn kan ik deze mondeling tijdens het beoordelingsgesprek toelichten.
Tijdens de lessen hebben we beperkt uitleg gehad wat ERD’s en Joins betreft. Met wat hulp van studiegenoten en YouTube tutorials is het me gelukt om de huidige website in een entity relationship diagram te plaatsen. Zoals het systeem nu werkt is bovenaan de afbeelding te zien. Pas nadat ik mijn structuur had gebouwd en al deels toegepast kregen we uitleg over de verschillende soorten relaties die er zijn. In het vervolg zou ik het anders hebben opgebouwd. Omdat ik aan wil tonen dat ik weet hoe dit moet heb ik daar ook een uitwerking van gemaakt, deze is aan de onderzijde van de afbeelding hieronder te zien.
Een user story (could have) welke ik gemaakt had was het werken met geautomatiseerde e-mails. Wanneer een klant een account aanmaakt en een reservering plaatst was het de bedoeling dat deze een bericht zou ontvangen met de relevante informatie. Omdat het werken met een externe emailserver redelijk wat werk met zich meebrengt heb ik ervoor gekozen om met PHPMailer te werken. Dit is een library welke via PHP (server side) werkt.
Deze library heb ik in mijn mappenstructuur opgenomen en door middel van een ‘require once’ roep ik deze op. Vervolgens heb ik de basis variabelen in een functie geplaatst zodat ik het makkelijk kan oproepen als ik ergens een e-mail wil verzenden. Hieronder heb ik afbeeldingen van mijn code met in de code annotaties ter verduidelijking.
Library + gemaakte HTML e-mail templates met variabelen %variabel% 
PHPMailer includen en in functie zetten met vooraf gevulde data en variabelen 
E-mail versturen d.m.v. gemaakte PHPMailer functie na registratie 
E-mail naar klant + eigenaar versturen d.m.v. gemaakte PHPMailer functie na maken afspraak
Data
Je hebt een webapplicatie gebouwd op de server die gevoed wordt door een database. De database inhoud kan gelezen, bewerkt en verwijderd worden.
Het reserveringssysteem haalt en stuurt alle data via een MySQLi database door middel van query’s. Ik maak gebruik van veel querytypes. Denk hierbij aan select, insert, update en delete. Hieronder staan enkele stukken code waarbij de werking van de code en database zichtbaar is. Ook de database zelf is te zien.
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.
De website is enkel te bezoeken als je ingelogd bent. Op de indexpagina moet je jezelf direct registreren of via de onderstaande knop naar de inlogpagina. Zodra je ingelogd bent wordt er een sessie gevuld welke je toegang geeft tot het gebruikersgedeelte van het systeem. Ook is er een admin-omgeving aanwezig, door middel van een in de php-bestanden gecodeerd e-mailadres wordt geverifieerd of er wel/geen admin inlogt op de website.
Als het password_verify overeenkomt $_SESSION[“email”] vullen -> redirect 
Iedere pagina checkt of de sessie gevuld is, dan krijg je toegang 
In het menu wordt gecheckt of de admin ingelogd is, dan wordt een extra pagina zichbaar
Alle input velden (text, date, time) gaan via een MySQLi real escape string naar de database om ervoor te zorgen dat het niet mogelijk is om code te injecteren. Mysqli_real_escape_string(connection, escapestring). Ook is er in de MySQLi database aangegeven welk type data verwacht wordt met daarbij een maximum aantal karakters. (Klik op de afbeeldingen om deze fullscreen te openen)
Types en limieten 
Alle inputs door de functie halen 
MySQLi_real_escape_string functie
Wachtwoorden worden uiteraard gehashed voordat deze naar de server gaan. En tijdens het inloggen wordt het door de gebruiker ingevoerde wachtwoord vergeleken met het hashed wachtwoord wat in de database staat. Dit gebeurt door middel van de password_verify functie. (Klik op de afbeeldingen om deze fullscreen te openen)
Wachtwoord doorsturen Regel 22+23 password_hash 
Password verify hash uit database 
Hash in de database
