URL personalizzati Dispatcher

Sommario

<- Precedente: Dispatcher Flush

Panoramica

Questo documento ti aiuta a capire come l’AEM gestisce gli URL personalizzati e alcune tecniche aggiuntive che utilizzano regole di riscrittura per mappare il contenuto più vicino al limite della consegna

Cosa sono gli URL personalizzati

Se il contenuto risiede in una struttura di cartelle, non sempre si trova in un URL di facile riferimento. Gli URL personalizzati sono come scelte rapide. URL più brevi o univoci che fanno riferimento a dove si trova il contenuto reale.

Esempio: /aboutus ha puntato a /content/we-retail/us/en/about-us.html

Gli autori dell’AEM possono impostare le proprietà dell’URL personalizzato su un contenuto nell’AEM e pubblicarlo.

Affinché questa funzione funzioni, è necessario regolare i filtri Dispatcher per consentire il reindirizzamento. Questa operazione non è più ragionevole se si regolano i file di configurazione di Dispatcher alla velocità con cui gli autori dovrebbero impostare le voci di pagine personalizzate.

Per questo motivo, il modulo Dispatcher dispone di una funzione che consente automaticamente tutto ciò che è elencato come reindirizzamento nella struttura del contenuto.

Come funziona

Creazione di URL personalizzati

L'autore visita una pagina in AEM, fa clic sulle proprietà della pagina e aggiunge voci nella sezione URL personalizzato. Quando si salvano le modifiche e si attiva la pagina, il reindirizzamento viene assegnato alla pagina.

Gli autori possono inoltre selezionare la casella di controllo Reindirizza Vanity URL quando si aggiungono Voci Vanity URL. In questo modo gli URL personalizzati si comportano come reindirizzamenti 302. Ciò significa che al browser viene richiesto di passare al nuovo URL (tramite l'intestazione di risposta Location) e il browser effettua una nuova richiesta al nuovo URL.

Interfaccia utente touch:

Finder contenuti classico:

Risoluzione/mappatura risorse

Ogni voce di reindirizzamento è una voce di mappatura sling per un reindirizzamento interno.

Le mappe sono visibili visitando la console Felix delle istanze dell'AEM ( /system/console/jcrresolver )

Ecco una schermata di una voce mappa creata da una voce di reindirizzamento:

Nell'esempio precedente, quando si chiede all'istanza AEM di visitare /aboutus, viene risolto in /content/we-retail/us/en/about-us.html

Filtri di Dispatcher per l’autorizzazione automatica

Dispatcher in uno stato protetto esclude le richieste nel percorso / tramite Dispatcher perché si tratta della radice della struttura JCR.

È importante assicurarsi che gli editori consentano solo il contenuto da /content e altri percorsi sicuri e così via, e non percorsi come /system.

Il problema è che gli URL personalizzati si trovano nella cartella base di /, quindi come possiamo consentire loro di raggiungere gli editori in modo sicuro?

Simple Dispatcher dispone di un meccanismo di filtro automatico per l'autorizzazione. È necessario installare un pacchetto AEM e quindi configurare Dispatcher in modo che punti alla pagina del pacchetto.

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

Nel file farm di Dispatcher è presente una sezione di configurazione:

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

Il parametro /delay, misurato in secondi, non funziona in base a intervalli fissi, ma in base a una verifica basata su condizioni. Dispatcher valuta la marca temporale della modifica di /file (che memorizza l'elenco degli URL personalizzati riconosciuti) al ricevimento di una richiesta per un URL non elencato. /file non verrà aggiornato se la differenza di tempo tra il momento corrente e l'ultima modifica di /file è inferiore alla durata di /delay. L'aggiornamento di /file si verifica in due condizioni:

Questo meccanismo è progettato per proteggere dagli attacchi Denial of Service (DoS), che altrimenti potrebbero sopraffare Dispatcher con le richieste, sfruttando la funzione URL personalizzati.

In termini più semplici, /file contenente URL personalizzati viene aggiornato solo se arriva una richiesta per un URL non già in /file e se l'ultima modifica di /file è stata più lunga rispetto al periodo /delay.

Per attivare in modo esplicito un aggiornamento di /file, è possibile richiedere un URL inesistente dopo aver verificato che sia trascorso l'intervallo di tempo /delay richiesto dall'ultimo aggiornamento. Gli URL di esempio per questo scopo includono:

Questo approccio forza Dispatcher ad aggiornare /file, a condizione che l'intervallo /delay specificato sia trascorso dall'ultima modifica.

Memorizza la cache della risposta nell'argomento /file, quindi in questo esempio /tmp/vanity_urls

Quindi, se visiti l’istanza dell’AEM all’URI, puoi vedere cosa recupera:

È letteralmente una lista, molto semplice

Riscrivi regole come regole personalizzate

Perché citare l’utilizzo di regole di riscrittura invece del meccanismo predefinito integrato nell’AEM come descritto sopra?

Semplicemente perché i problemi di spazio dei nomi, le prestazioni e la logica di livello superiore possono essere gestiti meglio.

Passiamo ora a un esempio della voce di reindirizzamento /aboutus per il suo contenuto /content/we-retail/us/en/about-us.html utilizzando il modulo mod_rewrite di Apache per eseguire questa operazione.

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

Questa regola cerca il reindirizzamento /aboutus e recupera il percorso completo dal renderer con il flag PT (Pass Through).

Inoltre, interrompe l’elaborazione di tutte le altre regole con flag L (Last), il che significa che non deve esaminare un lungo elenco di regole come nel caso del Resolving JCR.

Oltre a non dover delegare la richiesta, e aspettare che l'editore AEM risponda questi due elementi rendono questo metodo molto più performante.

La ciliegina sulla torta qui è il flag NC (No Case-Sensitive), che significa che se un cliente digita l'URI con /AboutUs invece di /aboutus, questo funziona ancora.

Per creare una regola di riscrittura per eseguire questa operazione, è necessario creare un file di configurazione in Dispatcher (ad esempio: /etc/httpd/conf.d/rewrites/examplevanity_rewrite.rules) e includerlo nel file .vhost che gestisce il dominio che richiede l'applicazione di questi URL personalizzati.

Di seguito è riportato un frammento di codice di esempio da includere 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>

Quale metodo e dove

L’utilizzo dell’AEM per controllare le voci vanity presenta i seguenti vantaggi

L'utilizzo di mod_rewrite per controllare le voci di reindirizzamento presenta i seguenti vantaggi

Utilizza entrambi i metodi, ma ecco i consigli e i criteri su quale utilizzare quando:

Successivo -> Registrazione comune