Dispatcher Vanity URL's

Inhoudsopgave

<- Vorige: Dispatcher flushing

Overzicht

Dit document helpt u begrijpen hoe AEM omgaat met ijdelheidsURL's en enkele extra technieken die regels herschrijven gebruiken om inhoud dichter bij de rand van levering in kaart te brengen

Wat zijn Vanity URL's

Wanneer u inhoud hebt die in een omslagstructuur leeft die steek houdt het niet altijd in een URL leeft die gemakkelijk om is te verwijzen. Vanity URL's zijn vergelijkbaar met sneltoetsen. Kortere of unieke URL's die verwijzen naar waar de echte inhoud zich bevindt.

Een voorbeeld: /aboutus punst bij /content/we-retail/us/en/about-us.html

AEM Auteurs hebben een optie om URL-eigenschappen van het type vanity in te stellen voor inhoud in AEM en deze te publiceren.

Deze functie werkt alleen als u de Dispatcher-filters aanpast zodat de ijdelheid erdoor heen kan. Dit wordt onredelijk om met het aanpassen van de de configuratiedossiers van Dispatcher aan het tarief te doen dat de auteurs deze punten van de ijdelheidspagina zouden moeten plaatsen.

Daarom heeft de Dispatcher-module een functie waarmee automatisch alles wordt toegestaan dat als een ijdelheid in de inhoudsstructuur wordt vermeld.

Hoe werkt het

URL's van Auteurs Vanity

De auteur bezoekt een pagina in AEM, klikt de paginaeigenschappen, en voegt ingangen in de sectie van de Vanity URL toe. Als u de wijzigingen opslaat en de pagina activeert, wordt de ijdelheid aan de pagina toegewezen.

De auteurs kunnen Redirect van de Vanheid URL checkbox ook selecteren wanneer het toevoegen van Vanity URL ingangen, dit veroorzaakt ijzelaars om zich als 302 redirects te gedragen. Dit betekent dat de browser wordt gevraagd naar de nieuwe URL (via Location antwoordheader) en dat de browser een nieuwe aanvraag doet voor de nieuwe URL.

Aanraakinterface:

Klassieke inhoudszoeker:

Resolving/toewijzing van bronnen

Elk ijdelingitem is een sling map-item voor een interne omleiding.

De kaarten zijn zichtbaar door de AEM instanties van de console van Felix ( /system/console/jcrresolver) te bezoeken

Hier volgt een schermafbeelding van een kaartitem dat is gemaakt door een ijdelingvermelding:

In het bovenstaande voorbeeld wanneer we de AEM-instantie vragen /aboutus te bezoeken, wordt het omgezet in /content/we-retail/us/en/about-us.html

Dispatcher-filters voor automatisch toestaan

De Dispatcher in een veilige status filtert verzoeken uit op het pad / via de Dispatcher, omdat dat de basis is van de JCR-structuur.

Het is belangrijk om ervoor te zorgen dat uitgevers alleen inhoud van /content en andere veilige paden toestaan, enzovoort, en geen paden zoals /system .

Hier ziet u de rub, ijdelheid-URL's die zich bevinden in de basismap van / , dus hoe kunnen we ze toestaan om de uitgevers te bereiken terwijl ze veilig blijven?

Eenvoudige Dispatcher heeft een mechanisme voor automatisch filteren. U moet een AEM installeren en vervolgens de Dispatcher zodanig configureren dat deze naar die pakketpagina wijst.

https://experience.adobe.com/#/downloads/content/software-distribution/en/aem.html?package=/content/software-distribution/en/details.html/content/dam/aem/public/adobe/packages/granite/vanityurls-components

Dispatcher heeft een configuratiesectie in zijn landbouwbedrijfdossier:

/vanity_urls {
    /url    "/libs/granite/dispatcher/content/vanityUrls.html"
    /file   "/tmp/vanity_urls"
    /delay  300
}

De parameter /delay, gemeten in seconden, werkt niet met een vaste intervalbasis, maar met een op voorwaarde gebaseerde controle. De Dispatcher beoordeelt de tijdstempel van de wijziging van /file (waarin de lijst met herkende vanity-URL's wordt opgeslagen) wanneer een aanvraag voor een niet-vermelde URL wordt ontvangen. /file wordt niet vernieuwd als het tijdverschil tussen het huidige moment en de laatste wijziging van /file kleiner is dan de duur van /delay . Het vernieuwen van /file vindt plaats onder twee voorwaarden:

Dit mechanisme wordt ontworpen om tegen Ontkenning van de aanvallen van de Dienst (Dos) te beschermen, die anders Dispatcher met verzoeken kon overweldigen, die de eigenschap van Vanity URLs uitbuiten.

Eenvoudiger gezegd, wordt /file die vanity URLs bevat slechts bijgewerkt als een verzoek voor een URL aankomt niet reeds in /file en als de laatste wijziging van /file langer geleden dan de /delay periode was.

Als u expliciet wilt dat de functie /file wordt vernieuwd, kunt u een niet-bestaande URL aanvragen nadat u hebt gecontroleerd of de vereiste /delay -tijd sinds de laatste update is verstreken. Voorbeeld-URL's voor dit doel zijn:

Deze benadering dwingt de Dispatcher om /file bij te werken, op voorwaarde dat het opgegeven /delay -interval is verstreken sinds de laatste wijziging.

De cache van de reactie wordt opgeslagen in het argument /file , dus in dit voorbeeld /tmp/vanity_urls

Dus als u de AEM-instantie in de URI bezoekt, ziet u wat deze ophaalt:

Het is letterlijk een lijst, super simpel

Regels herschrijven als Vanity Rules

Waarom zouden wij het gebruiken van herschrijven regels in plaats van het standaardmechanisme noemen dat in AEM zoals hierboven beschreven wordt gebouwd?

Uitgelicht eenvoudig, namespace kwesties, prestaties, en hoger-vlakke logica die beter kunnen worden behandeld.

Laten we een voorbeeld van de ijdelheid-vermelding /aboutus doornemen naar de inhoud /content/we-retail/us/en/about-us.html met de module mod_rewrite van Apache.

RewriteRule ^/aboutus /content/we-retail/us/en/about-us.html [PT,L,NC]

Deze regel zoekt naar de ijdelheid /aboutus en haalt de volledige weg van renderer met de vlag van PT (pas door).

Het houdt ook op met het verwerken van alle andere regels L-markering (Last), wat betekent dat het niet nodig is om een enorme lijst regels te doorlopen, zoals JCR Resolving.

Samen met het moeten niet volmacht het verzoek, en wachten op de AEM uitgever om deze twee elementen van deze methode te antwoorden maakt het veel uitvoerbaarder.

Dan is het icing op de cake hier de markering NC (Geen case-Sensitive) die betekent als een klant URI met /AboutUs in plaats van /aboutus typt het nog werkt.

Als u hiervoor een herschrijfregel wilt maken, maakt u een configuratiebestand op de Dispatcher (bijvoorbeeld: /etc/httpd/conf.d/rewrites/examplevanity_rewrite.rules ) en neemt u dit op in het .vhost -bestand dat het domein afhandelt waarvoor deze ijdelheidsURL's moeten worden toegepast.

Hier volgt een voorbeeld van een codefragment of include-bestand in /etc/httpd/conf.d/enabled_vhosts/we-retail.vhost

<VirtualHost *:80>
 ServerName weretail.com
 ServerAlias www.weretail.com
        ........ SNIP ........
 <IfModule mod_rewrite.c>
  ReWriteEngine on
  LogLevel warn rewrite:info
  Include /etc/httpd/conf.d/rewrites/examplevanity_rewrite.rules
 </IfModule>
        ........ SNIP ........
</VirtualHost>

Welke methode en waar

Het gebruik van AEM om ijdelingangen te controleren heeft de volgende voordelen

Het gebruik van mod_rewrite om items met een ijdelheid te besturen, heeft de volgende voordelen

Gebruik beide methoden, maar u kunt de volgende adviezen en criteria gebruiken:

Volgende -> Gemeenschappelijke Logboekregistratie