By Danny Paul van Iersel, 20-11-2024
We hebben bijvoorbeeld een website die een showcase is van producten. Wij willen dat elk product een unieke pagina heeft met de details en mogelijke functionaliteiten (bijvoorbeeld om een dealer te vinden of het specifieke product te kopen).
Zonder enige ontwikkeling zou je dit op één manier kunnen doen.
Maak een Contenttype voor pagina's aan, als voorbeeld een Productdetailspagina.
Voeg een veld met het gegevenstype ‘Inhoudsitems’ toe en configureer het zodat dit het type vertegenwoordigd wat u wenst. In ons geval een Product.
Voor elk afzonderlijk product maken we nu een nieuwe pagina en verwijzen we naar het product dat het moet bevatten.
Met een paar pagina's kan dit snel worden gedaan, maar als u veel producten heeft, kan het tijdrovend worden om elke pagina handmatig te maken.
De Wildcard-pagina functioneert als een sjabloon. Het wordt voor alle producten gebruikt en hoeft slechts één keer te worden geconfigureerd.
Via parameters kunnen we de selectie van ons Content Item vanuit de Content Hub aanpassen.
Voor onze pagina moeten we specifieke widgets bouwen die het parameterverzoek afhandelen om de overeenkomstige velden voor inhoudsitems weer te geven.
Als voorbeeld:
Hoe u de parameter kunt opgeven die voor deze pagina moet worden gebruikt?
Er zijn meerdere manieren om dit te doen. We zullen er 2 van bespreken in dit artikel:
Het gebruik van de query string is een eenvoudige methode om uw ontwikkeling te starten en te zien of uw componenten doen wat ze moeten doen.
Binnen een component kunt u binnen uw Widget eenvoudig een querystring opvragen en deze in uw query gebruiken om het gewenste Herbruikbare Content Type te selecteren.
Het gemakkelijke deel van deze oplossing is dat we ons geen zorgen hoeven te maken over de Kentico Content Tree-routering. Omdat de pagina bestaat, werkt deze nog steeds als een normale pagina. (Later hebben we het er meer over, waarom het belangrijk is).
Als we een pagina-URL hebben: “https://{{uw-domein}}/products/productwildcardpage”.
Het is hierbij mogelijk dat we de pagina opvragen zonder enige parameters. Dit moeten we natuurlijk wel opvangen. Dit kunnen we doen door een bericht te tonen aan een bezoeker dat de opgevraagde pagina niet geldig is.
Vervolgens moeten we een unieke identificatie voor ons product vinden. Dit kan een naam zijn, maar in sommige gevallen is dit niet uniek genoeg. Om het voorlopig simpel te houden, gebruiken we een product-ID.
Onze pagina URL zal zijn: “https://{{uw.domein}}/products/productwildcardpage?productid=1”.
We halen onze Kentico Content Hub-items op. (zie hoe u inhoudsitems kunt ophalen uit de Kentico-documentatie: https://docs.kentico.com/developers-and-admins/development/content-retrieval/retrieve-content-items)
Onze zoekopdracht gebruikt de productid-parameter en zoekt naar het item (hieronder een eenvoudige voorbeeldcode om de zoekopdracht te demonstreren):
U kunt ook alle items uit een contentrepository opvragen (zorg ervoor dat u deze op de juiste manier in de cache plaatst) en vervolgens het gewenste item selecteren:
Wees altijd bewust van uw Query string input.
Gebruik hash op de query string.
Om de hashing van een query string in te stellen, verwijzen we naar de Kentico-documentatie: https://docs.kentico.com/k12sp/securing-websites/developing-secure-websites/query-string-hashing
Gebruik de QueryHelper.BuildQueryWithHash / ValidationHelper.GetHashString om een hash te genereren. Gebruik vervolgens QueryHelper.ValidateHash / ValidationHelper.ValidateHash om de gehashte waarde op te halen. Dit is een veiligere manier en voorkomt dat er met de parameters van de query string wordt geknoeid.
Wanneer u query string toestaat en er geen aandacht aan besteedt, kan deze worden misbruikt voor SQL-injectie.
SQL-injectie is een aanval op data gestuurde applicaties. Het kan technieken gebruiken om databasekwetsbaarheden te vinden. Het kan instructies invoegen of zelfs hele gegevenstabellen verwijderen.
Om SQL-injectie te voorkomen:
U kunt gegevens laden via DataQuery of ObjectQuery met behulp van de standaard Kentico API-provider. Het maakt gebruik van parametergestuurde queries.
Als u een query gebruikt, kunt u de methoden WhereContains of WhereEquals gebruiken. Hiermee kunnen alleen specifieke query's worden uitgevoerd op opgegeven kolommen.
Met behulp van SQL-parameters worden de parameters als letterlijke tekst verwerkt en zal de SQL-server de code niet uitvoeren als de parameter ongeldige waarden bevat.
Escaping is een andere manier hiervoor. Door gebruik te maken van SqlHelper.EscapeQuotes en SqlHelper.EscapeLikeValue voorkomt het gebruik van apostroffen en jokertekens.
Een webapplicatiefirewall (of WAF) kan verkeer monitoren voordat het aan uw applicatie wordt doorgegeven. Het blokkeert verkeer als het niet veilig is en voorkomt SQL-injectie, Cross-site scripting en sommige WAF's kunnen ook worden geconfigureerd om DDOS-aanvallen te blokkeren.
Een macht der gewoonte die u misschien wilt gebruiken of waar u al bekend mee bent, zijn de ‘Zero-trust-principes’. Zero trust gaat verder dan alleen data, maar het is wel goed om te weten.
Controleer altijd uw invoer voordat u deze verder gebruikt.
Minimaliseer de toegang tot delen van uw gegevens. Maak verbinding met uw database met de minste vereiste toegang.
Als het gaat om gegevensinvoer, ga er dan altijd van uit dat deze kunnen worden gebruikt om uw systeem te doorbreken.
We zouden geen ontwikkelaars zijn als er gevallen zijn waarin de bedrijfsvereisten niet voldoen aan de bovenstaande oplossing. In sommige gevallen zijn wij genoodzaakt om SEO-vriendelijke URL’s te gebruiken.
Waarom zouden we SEO-vriendelijke URL’s willen gebruiken?
Om dit te kunnen gebruiken hebben we een unieke structuur nodig om het product toch te kunnen identificeren.
Afhankelijk van uw project of klant zijn sommige sleutels belangrijker dan andere. Voor dit voorbeeld gebruiken we de volgende sleutels om ons product te identificeren:
Dit resulteert in een URL zoals: {{uw.domein}}/ProductCategorie/Merk/Naam.
Als we CMS-oplossingen van verschillende soorten CMS-systemen verkopen en functies toevoegen, wordt het zoiets als: {{uw.domein}}/CMS/Kentico/Wildcard
We hebben het volgende nodig om onze code in te stellen om deze URL's te verwerken:
Het instellen van een route zou er als volgt uit kunnen zien in uw Program.cs bestand:
In onze Controller registeren we de RegisterWebPageRoute:
In onze methode voor “Detail” kunnen we de wildcard pagina ophalen.
We kunnen nu de Context Initializer gebruiken om onze wildcard pagina als context te gebruiken.
Kentico kan onze pagina nu weergeven op basis van de route. Het enige wat we nu moeten doen is de gegevens verzamelen op basis van onze parameters. Om onze Content Hub-gegevens te verkrijgen, kunnen we deze gegevens opslaan in een View Model en doorgeven aan andere componenten/widgets die op onze wildcard-pagina zijn geplaatst.
Met een beetje ontwikkelingswerk kunnen we zeer herbruikbare inhoud creëren.
Dit zorgt ervoor dat marketeers minimale inspanningen leveren om inhoud te creëren en deze toegankelijk te maken voor uw kanalen.
De voordelen van het gebruik van wildcardpagina's zijn dat een marketeer zich slechts op één plek zorgen hoeft te maken over de inhoud. Wanneer u een wildcardpagina bewerkt, hoeft u dit slechts één keer te doen. Bijvoorbeeld wanneer u een nieuwe widget of functionaliteit aanmaakt. Alle presentaties van uw producten worden in één keer bijgewerkt. In plaats van alle afzonderlijke pagina's één voor één te moeten doorlopen.
Wilt u weten hoe wij bij Blastic u kunnen helpen uw gebruikerservaring te optimaliseren? Neem gerust contact met ons op.
Klaar om je digitale ervaring naar een hoger niveau te tillen? Neem gerust contact met ons op voor meer informatie over onze diensten en hoe we jou kunnen helpen het volledige potentieel van je digitale marketing te benutten.
Neem contact op met één van onze consultants om de perfecte match te vinden die bij je past en waarmee je kunt groeien.