Inleiding
Het internet bestaat uit PC’s en servers die onderling met elkaar verbonden zijn. In de jaren ’60 is dit wereldwijde netwerk (het ‘web’) ontstaan uit het Arpanet, een door het Amerikaanse ministerie van Defensie ontwikkeld militair communicatie-netwerk. In verband met de dreiging van een atoomconflict met de SU moest een netwerk van onderling verbonden computers, ervoor zorgen dat een aantal strategische geografische posities in de VS met elkaar konden blijven communiceren, ook als er een positie zou uitvallen.
Later werd dit militaire netwerk voor algemeen gebruik uitgebreid door een groep Amerikaanse universiteiten, die onderling via computers pakketjes met informatie gingen rondsturen.
Professor Leonard Kleinrock slaagde er op 21 oktober 1969 als eerste in om via een computer op zijn Amerikaanse universiteit UCLA verbinding te maken met een computer in het Stanford Research Institute. Hij verstuurde het commando ‘LOGIN’. De L en de O werden probleemloos ontvangen, bij de G echter crashte het systeem. ‘LO’ was dus het eerste woord dat op het Arpanet, de voorloper van het internet, werd verzonden.
Er ontstonden rond dit aanvankelijke primitieve netwerk in de loop der jaren verschillende protocollen en talen die de uitwisseling van informatie (data) tussen een server en het tonen van informatie op een PC, en de informatie-uitwisseling op het ‘web’ in het algemeen, gingen verbeteren:
1. computer-verbindingsprocotol (http:// en https:// )
2. computer-programmeer-talen als PHP (Hypertext Preprocessor) en ASP (Active Server Pages) om informatie op te kunnen halen uit een database die lokaal op een server draait (server-side);
3. een opmaaktaal HTML (HyperTextMarkupLanguage) en CSS (Cascading Style Sheets) zorgt dat de informatie leesbaar getoond wordt in een browser (blader-software) op de PC .
4. browser-software (Chrome, Edge) om webpagina’s op te vragen binnen het netwerk door in het adresvenster van de browser een domeinnaam (=IP-adres) in te vullen en indien er een webpagina (index.php) opgevraagd kan worden op de webserver met dat IP-adres, binnen een hiërarchie van geclusterde pagina’s /overzicht/pagina te kunnen bladeren vanaf een PC (client-side).
5. de scripttaal Javascript voor scripts die worden uitgevoerd in de webbrowser om specifieke functies op de webpagina (interactiviteit als het verzenden van een formulier) functioneel te maken.
6. Javascript wordt ondersteunt door JQuery: een vrije JavaScript-library voor dynamische en interactieve websites, onder andere voor het bewerken van het DOM (Het Document Object Model is een objectgeoriënteerde benadering van gestructureerde documenten zoals HTML: feitelijk een standaard voor een hierarchische notatie van de html-soep; zodat elk object waar iets mee moet gebeuren een vaste positie krijgt) en CSS en interactie met de webserver (ook bekend als AJAX)
7.
Cookies zijn kleine stukjes data die websites naar je browser sturen om informatie te onthouden over jou als gebruiker. Het zijn stukjes tekst die worden opgeslagen als .txt bestand. Het is dus geen scriptje dat iets kan uitvoeren. Het is puur een paar regels tekst zonder code, die in de header can elk request wordt meegestuurd. Dat kan bijvoorbeeld zijn wat je in een winkelwagentje hebt gedaan, je loginstatus, of welke artikelen je al hebt bekeken. Ze zorgen ervoor dat je niet bij elk bezoek alles opnieuw hoeft in te stellen.De naam cookie in de context van computers stamt eigenlijk af van het begrip magic cookie, een term uit de vroege computerjaren. Dit was een klein, onzichtbaar gegevenspakketje dat werd doorgegeven tussen computerprogramma’s. Zo’n magic cookie functioneerde als een soort identificatiemiddel: het droeg informatie die door een ander programma kon worden opgepakt en herkend, zonder dat de gebruiker hier verder mee bezig was. Dit idee van een klein stukje data dat iets doorgeeft, werd later overgenomen toen webontwikkelaars een manier nodig hadden om gebruikersinformatie te onthouden tijdens surfsessies.
Magic cookie zelf heeft waarschijnlijk zijn naam te danken aan het idee dat het iets “kleins en verborgen” was dat iets speciaals of magisch kon doen – zoals een verborgen boodschap in een fortuinkoekje. Toen webcookies werden geïntroduceerd, werd dit idee overgenomen en ingekort tot simpelweg cookie, wat verwijst naar dat kleine stukje data dat tussen jou en een website wordt doorgegeven en onthouden.
Kortom, de naam cookie is een soort metafoor voor iets kleins en nuttigs dat ‘magisch’ werkt, een beetje zoals de verrassing in een koekje!
Wat gebeurt er ook al weer als je een website bezoekt?
Je vult in het adresvenster een url in. het Hypertext Transfer Protocol zorgt ervoor dat een een browser op een PC een html-pagina kan opvragen die zich op een server bevindt elders. Als je een website bezoekt die cookies gebruikt, stuurt de browser elke keer bij een nieuwe pagina-aanvraag (zoals wanneer je doorklikt naar een andere pagina op de site) de relevante cookies mee in de HTTP-header van die aanvraag. Hierdoor kan de server herkennen dat jij dezelfde gebruiker bent, zonder dat je bijvoorbeeld opnieuw hoeft in te loggen.
De browser kan deze cookies dan bijhouden en weer doorsturen naar de website bij een volgend bezoek. Dit maakt het mogelijk dat websites bepaalde gegevens over je voorkeuren en sessie onthouden, zoals je loginstatus, instellingen of winkelwagentje.
Bestandsformaat en opslag
Een cookie is dus een tekstbestand met een .txt-extensie, en het bevat enkele basisgegevens zoals:
Naam van de cookie: Een unieke identificatie voor de cookie.
Waarde: Hierin zit de eigenlijke informatie die de website wil opslaan, zoals een sessie-ID.
Domein en pad: Het specifieke domein (website) en pad waar de cookie geldig voor is.
Vervaldatum: Wanneer de cookie automatisch gewist wordt. Dit kan een enkele sessie zijn (verwijderd als je de browser sluit) of langer.
Beveiligingskenmerk: Sommige cookies hebben een secure kenmerk dat ervoor zorgt dat ze alleen via een beveiligde HTTPS-verbinding verzonden worden.
Een cookie bevat enkel tekst; het is dus géén script of code die iets kan uitvoeren. Dit betekent dat een cookie zelf niets ‘actiefs’ doet en geen programma kan uitvoeren. Cookies worden opgeslagen als platte tekst en zijn niet bedoeld om code of functies uit te voeren. Dit is ook om veiligheidsredenen; een website zou bijvoorbeeld een stukje Javascript kunnen proberen toe te voegen aan een cookie om iets op je computer te doen, maar dat kan niet dankzij deze restrictie.
Waar worden cookies opgeslagen?
Afhankelijk van de browser worden cookies in verschillende directories opgeslagen, vaak in een submap van je gebruikersprofiel of browserprofiel op de computer. Hier staan de cookies als kleine tekstbestanden, soms per website of in een databaseachtig bestand, afhankelijk van de browser (bijvoorbeeld SQLite-bestanden in moderne browsers).
Hoe cookies werken in de browser
Als je een website bezoekt die cookies gebruikt, stuurt de browser elke keer bij een nieuwe pagina-aanvraag (zoals wanneer je doorklikt naar een andere pagina op de site) de relevante cookies mee in de HTTP-header van die aanvraag. Hierdoor kan de server herkennen dat jij dezelfde gebruiker bent, zonder dat je bijvoorbeeld opnieuw hoeft in te loggen.
Beheer en privacy
In de instellingen van je browser kun je meestal zien welke cookies actief zijn, ze beheren of verwijderen, en zelfs instellen dat ze automatisch gewist worden na een bepaalde tijd. Veel browsers bieden ook opties om cookies per website of volledig te blokkeren om de privacy te waarborgen.
Kortom: een cookie is een klein, eenvoudig tekstbestandje met vaste informatie en geen actieve code. Het wordt beheerd door je browser en stelt websites in staat om je voorkeuren of sessie-informatie te onthouden zonder direct risico te vormen voor de veiligheid.
Elke computer die is aangesloten op het internet of netwerk heeft een IP-nummer waarmee hij zichtbaar is voor alle andere computers op het internet. Men kan dit vergelijken met telefoonnummers. Om het mogelijk te maken dat computers elkaar kunnen vinden en identificeren, hebben deze hun eigen nummer nodig. Deze nummers zijn de IP-adressen. Een IP-adres is meestal gekoppeld op het internet aan een domeinnaam. Dat is feitelijk een letterreeks die makkelijker is te onthouden dan een cijferreeks. In het adresvenster van je browser kun je makkelijker een woord (zoals burkunk.nl) invullen dan het IP-adres dat gekoppeld is aan het domein burkunk.nl (34.240.160.162)
Maar een IP-adres kan ook gekoppeld zijn aan een internetverbinding. Dat is meestal de wifi router waarmee je contact zoekt via je ISP (internet service provider met het web). En natuurlijk het device waarmee je het internet opgaat via je wifi-verbinding heeft ook een interne IP-adres dat wordt toegewezen vanuit je router.
Het externe of publieke IP adres is het adres waarmee je aan internet bent verbonden; dit IP-adres is afhankelijk van je access provider. Dit IP adres is dus eigenlijk de buitenkant van je internet router.
In ons geval is dit de Ziggo-router van wifi: ISP Ziggo: 213.127.114.228
Dat is ons publieke IP-adres.
Intern, dus alle apparaten die binnenshuis met internet zijn verbonden, hetzij via een UTP kabel, hetzij via WiFi, hebben een eigen intern IP adres. Dit zijn IP adressen uit een privé reeks, meestal beginnend met 10.x.x.x, 172.16.x.x of 192.168.x.x. Deze interne IP adressen zijn niet routeerbaar en standaard niet te bereiken vanaf internet. Die worden toegewezen door de router dmv DHCP
(“Dynamic Host Configuration Protocol”)
Wij hebben via Ziggo als intern IP-adres: 192.168.68.xx.
Mijn iPhone binnen wifi bijv heeft 192.168.68.109
Mijn Mac Book PRo heeft 192.168.68.123
WifiMac 88:66:5a:03:5c:25
Het IP-adres is opgebouwd uit cijfers. Er is een officiële instantie die sinds het ontstaan van het internet deze cijfers toewijst. Het IANA. (Internet Assigned Numbers Authority)
Tot nu toe gebruikt men voornamelijk IP-adressen die bestaan uit 32 bits, het zogenaamde Internet Protocol versie 4-systeem (IPv4), maar met de groei sinds 1990 blijkt dit te weinig adressen op te leveren en gaat men over tot Internet Protocol versie 6 (IPv6) ontwikkeld, met IP-adressen bestaande uit 128 bits.
In IPv4 is een IP-adres een reeks van 32 bits. De adresruimte van IPv4 bevat daarom maximaal 232 = 4.294.967.296 IP-adressen. Nu zijn er 7,6 miljard mensen op aarde dus dat is uiteindelijk te weinig.
Bovendien zijn een aantal IP-adressen gereserveerd als broadcastadres (begrijp ik niet), als testadressen en hebben sommige bedrijven en IT-providers veel meer nummers toegewezen gekregen dan zij gebruiken.
Het is gebruikelijk een IP-adres uit IPv4 op te delen in vier groepen van 8 bits en deze weer te geven in de vorm van door punten gescheiden decimale getallen, bijvoorbeeld 192. 0 .2 . 197 .
Dit is korter dan de 32 bits en eenvoudiger te lezen (begrijp ik niet). Elk van de vier getallen ligt tussen 0 en 255, beide inbegrepen. Voor de mens zijn zulke combinaties van vier getallen echter ook nog moeilijk te onthouden.
Om het tekort aan geldige IP-adressen op te lossen heeft men het IPv6 gepresenteerd.
In IPv6 zijn er 128 bits beschikbaar voor een IP-adres, en is de theoretische bovengrens dus 2128 ≈ 3,4 ×1038 IP-adressen. Net als bij IPv4 geldt dat in de praktijk weer adressen gebruikt worden als netwerkadres en broadcastadres, maar evengoed is het aantal toe te kennen IP-adressen hiermee enorm groot: triljarden adressen per persoon.
In het IPv6 protocol hanteert men een andere notatie dan de vier groepen cijfers: IPv6-adressen zijn 128 bits lang en worden normaal geschreven als 8 groepen van 4 hexadecimale cijfers, gescheiden door dubbele punten:
2001:| 0db8|:85a3: | 0000😐 1319:| 8a2e😐 0370:| 7344
is een geldig IPv6-adres.
Het Domain Name System (DNS) is het systeem en netwerkprotocol dat op het internet gebruikt wordt om namen van computers naar numerieke adressen (IP-adressen) te vertalen en omgekeerd. Hoewel dit “vertalen” genoemd wordt, is het niet meer dan opzoeken van namen in tabellen waaraan nummers gekoppeld zijn.
DNS is een client-serversysteem: een opvrager (client) gebruikt het DNS-protocol om aan een aanbieder (DNS-server van je provider waarbij je een domeinnaam host) een naam of adres op te vragen, waarop die server een antwoord terugstuurt. Het opzoeken van een nummer bij een naam wordt forward lookup genoemd; het opzoeken van een naam bij een nummer reverse lookup.
De meeste providers hebben een primary (eerste) name server en een secondary (tweede) name server, het is ook mogelijk dat een provider meer dan twee name servers heeft. Mijndomein heeft er bijv. 3: nsn1.mijndomein.nl, nsn2.mijndomein.nl en nsn3.mijndomein.nl
Het Domain Name System wordt gevormd door name servers. Elke name server is verantwoordelijk voor een bepaald gebied. Dit werkt als volgt:
Het hele proces duurt maar een paar seconden. Dit is natuurlijk afhankelijk van de snelheid van je internet verbinding. Een Domein Naam Systeem onthoudt de informatie een paar dagen. Daarna, als er weer een nieuwe aanvraag voor die domeinnaam is, doet hij weer een update.
DNS in praktische implementaties bestaat uit drie onderdelen:
Het opzoeken van data met behulp van DNS wordt in de regel een lookup genoemd. Software, zoals een webbrowser, die een lookup wil doen vraagt dit aan de stub resolver. Dit is relatief simpele software die, afhankelijk van de configuratie, de vraag kan stellen aan een recursor of eerst kan kijken in een bestand (zoals het o.a. Unix-afgeleiden bekende /etc/hosts).
Bij het opzoeken van een domein wordt begonnen op het hoogste niveau (root genaamd) en daarna wordt steeds specifieker gezocht. Bij het zoeken naar een domein wordt meteen aan de DNS-rootserver gevraagd voor bijvoorbeeld nl.wikipedia.org. Er is geen tussenstap waarbij alleen om org gevraagd wordt. Het is immers theoretisch mogelijk dat de rootserver zelf al het antwoord voor nl.wikipedia.org weet. Zo weten rootservers bijvoorbeeld wel het antwoord voor a.root-servers.net. In de regel zal door de DNS-rootserver echter wel verwezen worden naar de nameservers voor org. Deze zou in het geval van nl.wikipedia.org dan verwijzen naar de nameservers voor wikipedia.org die vervolgens het antwoord weten.Vereenvoudigde weergave van recursie bij het resolven van nl.wikipedia.org
Deze servers waar de recursor vragen aan kan stellen zijn de authoritative nameservers. Deze zijn ook relatief dom en geven simpele antwoorden. Deze antwoorden zijn vaak in bestanden of in een database opgeslagen. Een authoritative nameserver kan een antwoord geven, wat zowel een verwijzing naar een andere server of een direct antwoord op de vraag kan zijn.
Zowel de recursor als de authoritative nameserver worden vaak samen DNS-server genoemd. Het is mogelijk om deze beide functies te combineren in één programma. Dit wordt bijvoorbeeld gedaan in BIND, een van de bekendste en meest gebruikte DNS-servers.
Data in DNS wordt opgeslagen in een Resource Record. Een resource record bevat een type, een TTL, een naam en data. De data kan bijvoorbeeld een IP-adres zijn of een andere naam. Dit is afhankelijk van het type van het resource record. Bij de Provider die je domeinnaam host kun je je eigen DNS-records beheren.
Veel voorkomende types zijn:
DNS wordt ook gebruikt in het SMTP-protocol om de mailservers voor een domein op te zoeken, de computers die de e-mail ontvangen die aan de desbetreffende organisatie geadresseerd is.
Korte time-to-livewaarden kunnen zorgen voor een grotere belasting op de autoritatieve nameserver, maar ze kunnen nuttig zijn wanneer het adres van een belangrijke service (zoals een webserver of een MX-record) wordt veranderd. DNS administratoren verlagen vaak de TTL van zo’n adres voordat het verandert om overlast voor de gebruikers te minimaliseren. Bij een lancering van een nieuwe site (gehost op een nieuwe server met een ander IP adrs) zal door een korte TTL het website-adres dat standaard naar het oude IP-adres verwijst nog maar kort in de lucht zijn. De tijd dat het adres naar het oude ip nummer verwijst is dan verkort naar een paar uur.
< Het internetprotocol http:// (Hypertext Transfer Protocol) zorgt ervoor dat een een browser op een PC een html-pagina kan opvragen die zich op een server bevindt elders. Via het HTTP-protocol zijn de manieren en regels afgesproken waarop computers met elkaar kunnen praten en informatie kunnen uitwisselen via het internet. Alle browsers (programma’s waarmee je website kunt bezoeken) en webservers (computers waar de website wordt gehost) praten volgens dit protocol
Dit protocol is gericht op het presenteren van informatie, maar houdt zich minder bezig met de manier waarop informatie van de ene plaats naar de andere wordt overgedragen. Dat betekent dat HTTP onderschept en mogelijk gemanipuleerd kan worden, waardoor zowel de informatie als de ontvanger ervan kwetsbaar worden. Zo kunnen bijvoorbeeld e-mail en NAW gegevens of een creditcard nummer die je in een formulier op een website in jouw persoonlijke browser op je PC invult en verzendt naar de server, via het standaardprotocol http:// makkelijk door de buitenwereld worden opgevangen. Daarvoor is https in de jaren ’10 van de 21ste eeuw geïntroduceerd om de domeinnamen veiliger te maken door een authenticatie-certificaat te introduceren.
Die ‘S’ in de http:// staat voor Secure (veilig) en aan de basis ervan ligt Transport Layer Security (TLS), de standaard beveiligingstechnologie die een versleutelde verbinding tot stand brengt tussen een webserver en een browser, waardoor de informatie die over de verbinding heen en weer gaat niet kan worden afgetapt/ontsleutelt.
Naast het versleutelen van de gegevens die tussen de server en je browser worden verzonden, authenticeert TLS ook de server waarmee je verbinding maakt (hij controleert of de server een geldig certificaat heeft – een bewijs van authenticiteit van de server: dat het webadres rabobank.nl ook echt geregistreerd staat als zijnde de bank en dat het bijvoorbeeld geen fishing site met dezelfde naam is waar een hele andere organisatie achterzit) en beschermt de verzonden gegevens tegen manipulatie.
Wanneer de website een echtheidscertificaat heeft verschijnt er een slotje voor het website-adres in de adresbalk van de browser. Je kunt dit open klikken en de mate van beveiliging lezen, wanneer het certificaat verloopt etc.
In HTTP is vastgelegd welke vragen (de Engelse term hiervoor is requests) een cliënt aan een server kan stellen en welke antwoorden (de Engelse term is responses) een webserver daarop kan teruggeven. Elke vraag bevat een URL die naar een webcomponent of een statisch object zoals een webpagina of plaatje verwijst.
Een HTTP-request bestaat uit de requestsoort, de URL, de headervelden (koptitelvelden) en eventueel een inhoud. Een overzicht van de HTTP-requestmethoden:
Een HTTP-response bestaat uit een resultaatcode, headervelden en een body (de boodschap). De resultaatcode bestaat uit minimaal drie cijfers. Het eerste cijfer is het belangrijkste:
De meest voorkomende resultaatcodes zijn:
Wanneer je een url (uniform resource locator) invult in het adresvenster van je browser, krijg je te maken met de volgende zaken:
Er zijn verschillende protocollen, bijvoorbeeld:
Hij bouwt een HTTP-verzoek op. Dit verzoek bevat de vraag om een specifieke webpagina (zoals example.com/page).
Bij dat verzoek stuurt de browser ook gegevens mee in de vorm van HTTP-headers. Dit zijn stukjes informatie die aangeven welke browser je gebruikt, of je een bepaalde taalvoorkeur hebt, en – belangrijk in dit geval – welke cookies je hebt opgeslagen voor die website.
Dus hoewel de HTML van de pagina op dat moment nog op de server staat, komt deze header wel al vanaf jouw browser. Het is dus eigenlijk een stukje communicatie dat jouw browser naar de server stuurt vóórdat de server antwoordt.
2. Hoe ziet een HTTP-header met cookies eruit?
Een HTTP-header met cookies kan er ongeveer zo uitzien, stel dat je op example.com bent ingelogd en een cookie hebt die je sessie onthoudt. Een HTTP-verzoekheader kan er zo uitzien:
http
Code kopiëren
GET /page HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36
Accept-Language: en-US,en;q=0.9
Cookie: session_id=abc123; theme=dark
Hier zie je een paar belangrijke onderdelen:
GET /page: Dit is het type verzoek; in dit geval vraagt de browser om een pagina op de server.
Host: example.com: Geeft aan voor welk domein dit verzoek bedoeld is.
User-Agent: Informatie over jouw browser, besturingssysteem, enzovoort.
Cookie: Hier worden alle cookies meegestuurd die relevant zijn voor example.com. In dit voorbeeld stuurt de browser twee cookies mee: session_id=abc123 en theme=dark.
De cookies worden dus als een soort ‘bagage’ met het verzoek meegegeven, en de server kan deze informatie gebruiken om te zien wie jij bent of om andere voorkeuren toe te passen.
3. De server verwerkt het verzoek en stuurt een antwoord
De server ontvangt dit verzoek en haalt informatie uit de cookies in de header. Op basis hiervan kan de server herkennen dat jij al ingelogd bent (op basis van session_id) en dat je een donker thema hebt gekozen (op basis van theme=dark). De server kan je dan direct de HTML-pagina sturen met jouw instellingen, zonder dat je opnieuw hoeft in te loggen of je voorkeuren opnieuw moet instellen.
De server stuurt vervolgens de HTML (en eventueel andere bestanden zoals CSS, JavaScript, afbeeldingen) als antwoord terug naar jouw browser, en jouw browser rendert dit tot de webpagina die jij ziet.
4. Is de HTTP-header een onderdeel van de browser?
Ja, de HTTP-header is een deel van de communicatie die je browser opbouwt. De browser is verantwoordelijk voor het samenstellen van het HTTP-verzoek, inclusief alle headers, en stuurt dit naar de server. Zodra de server reageert, ontvangt de browser de HTML en andere bestanden en zet deze om in de webpagina die je ziet. De HTTP-header zelf is niet zichtbaar in de webpagina, maar wordt wel elke keer meegestuurd bij een nieuwe pagina-aanvraag naar de server.
Kort gezegd: de browser is verantwoordelijk voor het toevoegen van de cookies aan de HTTP-header in elk verzoek naar de server. Op die manier helpt de HTTP-header bij het onderhouden van sessies en het toepassen van persoonlijke instellingen zonder dat de gebruiker opnieuw hoeft in te loggen of voorkeuren hoeft in te stellen.
Een voorbeeld van zo’n antwoord-header van de server kan er als volgt uitzien:
http
Code kopiëren
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Set-Cookie: session_id=abc123; Expires=Wed, 09 Jun 2024 10:18:14 GMT; Path=/; Secure; HttpOnly
Set-Cookie: theme=dark; Expires=Wed, 09 Jun 2024 10:18:14 GMT; Path=/
Hier zie je het volgende gebeuren:
Set-Cookie: Dit is de instructie die de server naar de browser stuurt om het cookie op te slaan. In dit geval worden er twee cookies gezet: session_id en theme.
Waarden: Elke cookie heeft een naam en een waarde, zoals session_id=abc123 en theme=dark.
Extra parameters: Er worden ook enkele eigenschappen toegevoegd, zoals:
Expires: Hier staat de vervaldatum van het cookie. In dit voorbeeld blijft het cookie geldig tot 9 juni 2024. Zonder Expires wordt het cookie als een session cookie gezien en gewist als je de browser sluit.
Path: Geeft aan op welke paden van de website het cookie geldig is (bijvoorbeeld / voor de hele website).
Secure en HttpOnly: Secure betekent dat het cookie alleen over HTTPS-verbindingen wordt verstuurd, en HttpOnly betekent dat het cookie niet toegankelijk is voor JavaScript, wat de veiligheid verhoogt.
Wat doet jouw browser met deze instructie?
Zodra de browser deze Set-Cookie-header ontvangt, gaat hij aan de slag:
De browser leest de Set-Cookie-instructie.
Vervolgens slaat de browser het cookie lokaal op in zijn eigen cookie-opslag (de cookie-database, zoals we eerder besproken hebben).
Bij een volgend bezoek aan dezelfde website stuurt jouw browser automatisch het opgeslagen cookie mee in het HTTP-verzoek, zodat de server weet wie jij bent en jouw voorkeuren al kent.
Maar komt er dan een .txt-bestand van de server?
Nee, er komt niet letterlijk een .txt-bestand van de server naar jouw browser. In plaats daarvan komt er een instructie (de Set-Cookie-header) in de HTTP-respons van de server naar jouw browser, die vertelt hoe en welk cookie de browser moet opslaan. De browser maakt vervolgens zelf een tekstbestand of een regel in zijn cookie-database aan met de gegevens uit deze Set-Cookie-header.
Waarom kan dit de laadsnelheid verbeteren?
Cookies kunnen de laadsnelheid verbeteren doordat ze voorkeuren en sessiegegevens onthouden. Hier zijn enkele manieren waarop dit werkt:
Sessiebeheer: Cookies zorgen ervoor dat je ingelogd blijft, zodat de server niet bij elke nieuwe pagina-aanvraag jouw identiteit hoeft te controleren. Dit maakt navigeren binnen een site sneller.
Instellingen onthouden: Voor dingen zoals thema-instellingen (theme=dark), taalvoorkeuren, of andere opties hoeft de website niet steeds opnieuw te vragen wat je voorkeuren zijn. Hierdoor kan de server sneller de juiste versie van een pagina aanbieden.
Caching-optimalisatie: Sommige cookies helpen om bepaalde elementen van de site sneller te laden door aan te geven welke delen van een pagina voor jou specifiek zijn en welke niet, zodat je niet onnodig veel data binnenhaalt.
Samenvattend: De server stuurt een instructie naar de browser om een cookie op te slaan, en de browser volgt die instructie. De cookie wordt vervolgens bij elk bezoek aan die website automatisch naar de server gestuurd, wat helpt om sessiegegevens en voorkeuren te onthouden, zonder dat je steeds opnieuw hoeft in te loggen of je instellingen opnieuw moet doorgeven.
Om te voorkomen dat je elke keer, wanneer je een zware site bezoekt (bijv. www.nos.nl met veel afbeeldingen en tekst, lang moet wachten totdat de pagina geladen is slaat je browser (bijv. Chrome) basis elementen van zo’n pagina op in het cachegeheugen. Elke keer als je weer die url invult dan zijn die elementen al geladen.
Caching technologie wordt om verschillende reden toegepast. Denk bijvoorbeeld ook aan het maken van quiz op een webpagina die je pauzeert en die je later voortzet. Hij onthoudt de antwoorden die je reeds hebt gegeven.
In de ‘geschiedenis’ van je browser kun je deze gegevens wissen. Ook veel gebruikte inlogcombi’s, auto fills van formulieren etc.
Het http protocol kent een aantal status codes. Wanneer de DNS server de ingevulde domeinnaam niet kan vinden en omzetten naar een IP-adres dan krijgt je bekende foutmelding: 404, ‘file not found’
400 Foute aanvraag
401: Niet geautoriseerd
402: Betaalde toegang
403: Verboden toegang
404: Niet gevonden
405: Methode niet toegestaan
406: Niet aanvaardbaar
Cookies zijn kleine stukjes tekst die websites op je computer kunnen opslaan en later weer opvragen. Als je een website in je browser opvraagt, maakt je browser verbinding met de webserver waarop de website wordt gehost. De webserver stuurt de website naar je browser, maar kan daarbij ook een cookie meesturen. Je browser bewaart die cookie vervolgen op je computer. De volgende keer dat je de website bezoekt, stuurt je browser de cookie weer terug naar de webserver bij het opvragen van de website.
Het kunnen functionele cookies zijn (bijv. je selecteert een taal en er wordt een cookie gebruikt om deze keuze te onthouden, je selecteert een product in een webshop en de winkelwagenpagina onthoudt je keuze, of je bent automatisch ingelogd dankzij een cookie) maar ook de meer gevaarlijke tracking cookies.
Trackers gebruiken cookies om je een unieke ID-code toe te wijzen die jou onderscheidt van alle andere internetters. Je browser stuurt braaf de trackingcookie met de unieke ID terug naar de tracker bij elke website die deze tracker bevat. Zo kan de tracker je eenvoudig volgen.
First-party-cookies zijn bijvoorbeeld de cookies die een webwinkel gebruikt om te onthouden wat er in je winkelmandje zit. Zij zijn afkomstig van de webserver van de site die je bezoekt en kunnen functioneel zijn. Je gebruikergemakt vergroten. Maar zoals je weet, kan een website externe onderdelen bevatten. Bijvoorbeeld een advertentie-banner of een tracker. Zo’n extern onderdeel kan zelf ook cookies plaatsen. Dat zijn third-party-cookies. Aangezien trackers vrijwel altijd externe onderdelen zijn, zijn zo’n beetje alle trackingcookies dus third-party-cookies.
Die Third Party cookies vertellen adverteerders welke site je eerder hebt bezocht. cross-domain tracking genoemd. Aan de hiervan kunnen er relevante advertenties getoond worden. Hoe?
Je gaat naar site A. Deze site heeft een banner van een derde partij (een ander domein en dus een andere server die dus ook op site A. Cookies kan plaatsen. , bijvoorbeeld Double Click van Google. Je krijgt in je cookies voorraad van je browser een unieke ID code van site A. Die is niet gebonden aan een domein. Kom je nu op Site B dan kan een tracker de unieke ID lezen van van de cookie van site A. De tracker weet dat je op A en B bent geweest. Toch begrijp ik dat niet goed. (uitzoeken)
https://www.wpbeginner.com/wp-themes/how-to-create-a-wordpress-child-theme-video/
A child theme is a WordPress theme that inherits the functionality, features, and style of another WordPress theme, the parent theme. You can then customize the child theme without making any changes to the parent theme.
Child themes are the best way to customize a WordPress theme because they save time and effort. The parent theme already contains lots of formatting and functionality, so you don’t have to code everything from scratch.
They also make it safe to update your WordPress themes. Because you modified the child theme and not the parent, you won’t lose any customization when you update the parent theme.
Een .php template binnen WordPress dicteert de lay-out van de html-pagina. Hij staat dus vol met php code-regels en vormt de communicatie met de html-pagina in het front-end (client-side) en de database (serverside). PHP (Hypertext Preprocessor) is een programmeertaal, terwijl HTML een opmaaktaal is.
https://www.strato.nl/hosting/php-tutorial-voor-beginners/
https://www.wpbeginner.com/wp-themes/how-to-create-a-full-width-page-in-wordpress/
Een robots.txt-bestand (zie: www.burkunk.nl/robots.txt of www.ntvg.nl/robots.txt) vertelt zoekmachinecrawlers welke URL’s op je site toegankelijk zijn voor de crawler. Dit wordt voornamelijk gebruikt om te voorkomen dat uw site wordt overbelast met verzoeken; het is geen mechanisme om een webpagina uit Google te houden!
