La riscrittura degli URL si riferisce al processo di modifica di un URL per renderlo più facile e accessibile agli utenti di Internet. In genere, questa modifica avviene per rendere l’URL più breve e più coerente. In questo modo, gli utenti lo ricorderanno e non avranno problemi a leggerlo o scriverlo in caso di necessità.

Al giorno d’oggi, gli utenti di Internet sanno che ci sono enormi rischi su Internet. E quando ci imbattiamo in un URL a coda lunga composto da numeri e lettere, tendiamo a diffidare.

Ecco perché è importante garantire la fiducia dei visitatori quando incontrano per la prima volta il suo URL, rendendolo breve e significativo.

Se ancora non riesce a capire il concetto di riscrittura degli URL, la invito a leggere attentamente questo articolo.

Capitolo 1: Che cos’è la riscrittura degli URL?

In questo capitolo, cercheremo di chiarire gli argomenti essenziali per darle un’idea chiara di cosa si intende per riscrittura degli URL.

1.1. Definizione di riscrittura degli URL

Quasi tutti i server, che siano Apache, Nginx, Microsoft IIS o altri, hanno la capacità di modificare gli URL prima che siano visibili ai ricercatori.

Questa modifica si verifica solitamente quando un documento richiesto si trova altrove e il visitatore deve essere reindirizzato alla nuova posizione.

Oltre a queste riscritture esterne, in cui un visitatore richiede un URL e il server verifica la presenza di determinati reindirizzamenti applicabili all’URL richiesto, ci sono anche le riscritture interne.

I server possono riconoscere rapidamente il documento o la risorsa che deve essere resa disponibile in un URL, indipendentemente dalla posizione in cui è memorizzata nella struttura interna delle cartelle.

Se prendiamo il caso di WordPress, ad esempio, ogni post del blog viene memorizzato in un database e gli viene assegnato un identificatore. Le singole pagine possono essere richieste sempre tramite questo ID.

1.2) Come funziona la riscrittura degli URL?

La funzione di riscrittura dell’URL si limita a collocare un livello sopra l’indirizzo originale e a trasformarlo in qualcosa di facile da trovare e sensato.

Dal punto di vista dell’utente, dopo la riscrittura, l’URL del sito web rimane lo stesso nel browser, ma più coerente

Ma dietro le quinte, il browser riscrive l’URL in questa confusione complicata e invia una richiesta ai server.

Le riscritture degli URL sono estremamente utili anche quando la struttura del server viene modificata e le risorse vengono spostate da una cartella all’altra

In questa situazione, un amministratore di sistema scriverà semplicemente la parte a cui punta l’URL amichevole

In pratica, poiché la risorsa è stata spostata, avrà una posizione diversa. Pertanto, è necessario un rewrite per puntare l’URL riscritto alla nuova posizione della risorsa

Questo non deve essere confuso con le funzioni di reindirizzamento che si verificano quando una risorsa è stata sostituita da una risorsa diversa.

1.3. Qual è l’importanza di riscrivere un URL?

È estremamente importante che gli URL abbiano un senso e diano un’idea della pagina a cui si riferiscono, pur essendo facili da capire per i motori di ricerca.

La riscrittura degli URL non mostra all’utente il funzionamento interno e le statistiche che si celano dietro l’indirizzo di un sito web, impedendogli di vedere le stringhe di query, il che non è vantaggioso per il sito.

Questo processo non è solo utile per coloro che lo visualizzano o lo leggono, ma contribuisce anche all’aspetto della sicurezza del sito, impedendo in larga misura l’hacking o l’accesso da parte di utenti malintenzionati

Mira a creare un URL ricco di parole chiave, il che significa includere la parola chiave nel testo dell’URL, che aiuterà efficacemente il processo SEO

Questo assicura che il sito in fase di sviluppo sia già in qualche modo ottimizzato prima ancora di essere lanciato.

Gli URL creati tendono anche a nascondere i link, che il più delle volte sembrano andare avanti e avanti.

Inoltre, lo stesso URL può continuare ad essere utilizzato, anche se c’è un cambiamento nel link originale.

Il processo di riscrittura degli URL può essere eseguito su qualsiasi tipo di sito o sistema di gestione dei contenuti web, sia che si tratti di un sito sviluppato con asp.net che di quelli creati con tecnologia PHP

Il processo di riscrittura degli URL avviene in base alle lingue e alle esigenze dei siti web

Questo sembra essere possibile con la tecnologia ASP.NET in modo efficiente, poiché è simile a Internet Information Server (IIS). Infatti, ASP.NET è un motore di scripting lato server (IIS) che produce pagine web interattive.

La riscrittura degli URL è possibile anche con PHP, grazie al modulo mod rewrite per il server Apache, tra gli altri.

Inoltre, sembrano anche essere facili da usare attraverso l’interfaccia. È anche utile se un utente desidera rimuovere una sezione dell’URL per navigare al livello successivo, il che è molto vantaggioso per lui.

Supponiamo che un utente arrivi alla pagina example.com/seo/recritture-url e voglia tornare alla home page. Possono semplicemente mantenere example.com ed eliminare le altre parti.

1.4. Perché la riscrittura degli URL è utile per la SEO?

Ci sono diversi vantaggi nell’utilizzare la riscrittura degli URL. In primo luogo, la riscrittura degli URL aiuta l’accessibilità e il miglioramento dell’esperienza dell’utente

In poche parole, quando un utente guarda un URL nei risultati di un motore di ricerca, non deve cercare di capire di cosa parla quella pagina o quell’articolo.

Inoltre, gli URL disordinati non incoraggiano le persone a cliccarci sopra, il che può portare a un tasso di clic inferiore. Questo è generalmente negativo per la SEO e le prestazioni del sito.

D’altra parte, gli URL amichevoli aiutano a ottimizzare i contenuti per la SEO

Un URL che includa il titolo dell’articolo e la parola chiave principale aiuterà l’indicizzazione su Google e la percezione del suo articolo o della sua pagina web da parte dei bot

Di conseguenza, gli URL ottimizzati per il SEO attraverso la riscrittura degli URL portano a una migliore visibilità, a una maggiore credibilità presso i suoi utenti e a un volume di traffico naturalmente più elevato.

Oltre a questo, l’utilizzo di riscritture di URL aiuta anche a mantenere la coerenza del percorso URL e della struttura del nome della pagina

Infine, le riscritture contribuiscono alle prestazioni anche attraverso la cache in modalità utente e la risoluzione dei problemi, in quanto si occupano di tracciare le richieste fallite.

1.5. Riscrittura degli URL vs. reindirizzamento

A differenza delle riscritture di URL, un reindirizzamento è un’azione lato client, non un’azione lato server.

Fondamentalmente, una riscrittura avviene quando l’indirizzo della risorsa cambia, oppure abbiamo bisogno di un livello più semplice, più facile da usare

Questo avviene dietro le quinte e l’utente non ne è consapevole. In confronto, un reindirizzamento avviene quando la risorsa non esiste più.

I reindirizzamenti possono verificarsi anche quando prevediamo il modo in cui un utente tenterà di accedere a una risorsa e configuriamo le funzioni di reindirizzamento per garantire che acceda correttamente alla risorsa.

Ad esempio, la risoluzione WWW è un’azione di reindirizzamento in base alla quale, indipendentemente dal modo in cui l’utente cerca la home page di Twaino, se utilizza il WWW. prima del nome di dominio o meno, arriverà sempre su Twaino.com.

Capitolo 2: Perché è importante fare la riscrittura degli URL?

Questo capitolo si concentra sul perché i webmaster dovrebbero fare una riscrittura.

2.1. Le applicazioni devono essere sicure

È importante che i webmaster proteggano i loro siti web da tutti i tipi di attacchi. Infatti, una persona non dovrebbe essere in grado di danneggiare il suo sito modificando un URL che punta alle sue applicazioni

Per garantire la sicurezza del suo sito, controlli tutte le variabili GET dei suoi visitatori.

Per esempio, diciamo che abbiamo un semplice script che visualizza tutti i prodotti di una categoria. Di solito si presenta così:

• myapp.php?target=showproducts&categoryid=123

Ma quando uno ScriptKiddie(tm) digita nella sua barra di navigazione myapp.php?target=showproducts&categoryid=youarebeinghacked, molti siti visualizzano messaggi di errore che lamentano l’utilizzo di una query SQL sbagliata, un ID risorsa MySQL non valido, ecc

Questo dimostra semplicemente che questi siti non sono affatto o molto sicuri.

2.2. Le applicazioni devono essere compatibili con i motori di ricerca

Non è generalmente noto, ma molti motori di ricerca non indicizzeranno a fondo il suo sito se contiene link a pagine dinamiche come quella citata sopra

Prendono semplicemente la parte “nome” dell’URL. Vale a dire, tutto ciò che precede il punto interrogativo, che contiene i parametri necessari alla maggior parte degli script per funzionare, e poi cercare di recuperare il contenuto della pagina

Per chiarire, ecco alcuni link dalla nostra pagina fittizia:

• myapp.php?target=showproducts&categoryid=123 ;
• myapp.php?target=showproducts&categoryid=124 ;
• myapp.php?target=showproducts&categoryid=125.

Purtroppo, c’è una buona probabilità che alcuni motori di ricerca cerchino di scaricare la pagina myapp.php.

Nella maggior parte dei casi, la chiamata di uno script come questo causerà un errore o non visualizzerà il contenuto appropriato a cui il link puntava

Provi a fare questa ricerca su google.com:

”c’è un errore nella sintassi sql” .php -forum

Noterà che ci sono sia errori enormi che minacce alla sicurezza negli script elencati

2.3. Le applicazioni devono essere facili da usare

Se il suo sito web utilizza un’applicazione come

quehttp://www.downloadsite.com?category=34769845698752354, la maggior parte dei suoi visitatori avrà difficoltà a tornare alla categoria preferita ogni volta che lascia la pagina principale del suo sito

Per l’utente è ancora più facile trovare l’URL nell’elenco a discesa dei browser quando digita nel campo “Posizione”, anche se ovviamente questo funziona solo se l’utente l’ha già visitato in precedenza.

Capitolo 3: Quali sono le regole per la riscrittura degli URL?

È ovvio che la riscrittura degli URL è un’opportunità per i siti di rendere i loro URL più facili da usare. Tuttavia, questa pratica deve seguire alcune regole per essere efficace e produrre gli effetti desiderati.

In questo capitolo, discuteremo le regole da seguire per riscrivere correttamente gli URL di un sito.

3.1) Come riscrivere un URL con IIS

Per riscrivere un URL con IIS, deve prima installare il software che può essere scaricato dalla piattaforma Microsoft.

Una volta installato, vedrà una nuova icona “Url Rewrite” nella console di gestione di IIS.

Passo 1: La console di gestione di IIS con la riscrittura degli URL aggiunta

Può gestire la riscrittura degli URL a livello di server o per singoli siti, come ritiene opportuno

Con il modulo di riscrittura degli URL, vedrà i “modelli” utilizzati. I modelli sono in una delle tre modalità

• Corrispondenza esatta
• I caratteri jolly; e
• E le espressioni regolari ECMAScript, che sono espressioni regolari compatibili con Perl.

Esistono due tipi di regole: in entrata e in uscita

Le regole in entrata esaminano gli URL delle richieste e li modificano. Mentre le regole in uscita ispezionano il traffico inviato, cercano gli URL che contiene e li riscrivono se necessario;

Questo è ancora più interessante quando il contenuto può utilizzare un URL assoluto che non è quello che l’utente dovrebbe ricevere;

Uno dei vantaggi della riscrittura degli URL è che supporta un certo numero di diverse regole integrate che rendono la vita più facile quando si vuole fare una riscrittura comune

L’elenco completo delle regole integrate è :

• Regola con mappa di riscrittura: le permette di definire un insieme di percorsi e le loro sostituzioni come un semplice elenco;
• Blocco della query: Vietare l’accesso a un percorso;
• URL di facile utilizzo: crea rapidamente regole per mappare i segmenti di percorso alle stringhe di query;
• Proxy inverso: consente al server corrente di fare da proxy inverso ad un altro;
• Imponi URL minuscoli: obbliga il cliente a utilizzare sempre URL minuscoli tramite un reindirizzamento HTTP 301 “Permanente”;
• Nome di dominio canonico: utilizza un reindirizzamento HTTP 301 “permanente” per garantire che i clienti utilizzino sempre il nome di dominio specificato;
• Aggiungi o rimuovi il simbolo della barra di separazione: questo aggiungerà o rimuoverà sempre la barra di separazione in un percorso URL che utilizza un reindirizzamento di stato HTTP 301 ‘Permanente’.

Passo 2: la creazione di una regola le permette di scegliere una regola incorporata da cui partire

Le regole integrate sono ottime perché, anche se vengono fornite con una procedura guidata personalizzata, se necessario, generano regole standard che può poi regolare o modificare in base alle esigenze.

La regola dell’URL facile da usare è molto popolare per coloro che non hanno un sistema che lo fa automaticamente

Si inizia inserendo un esempio di URL “brutto” di cui il sito ha effettivamente bisogno

Passo 3: creare una regola per l’URL amichevole

Un’altra delle regole integrate che la maggior parte utilizza è la regola del reverse proxy

Anche in questo caso, il sistema la guida attraverso una configurazione predefinita competente in quello che potrebbe essere un compito molto complesso

Contiene opzioni integrate e modificabili, come ad esempio:

• Se le risposte HTTPS debbano o meno essere sempre proxate a HTTP standard;
• Se desidera o meno utilizzare una regola in uscita per nascondere il nome del server interno

Le persone spesso lo utilizzano per poter impostare un server centrale con host web virtuali sullo stesso indirizzo IP, per gestire le richieste in arrivo che devono essere inviate a diversi server interni.

Figura D: Creazione di un reverse proxy

L’ultima regola di cui parleremo è quella delle mappe di riscrittura

Queste consentono di creare un elenco di URL e di tradurli in URL sostitutivi

Da sola, una mappa di riscrittura non è necessaria; dovrebbe essere utilizzata come parte di una regola più ampia, invece di o in combinazione con i modelli di sostituzione

Sono particolarmente utili quando si progetta o si riorganizza un sito che utilizza URL non prevedibili

Combinando un reindirizzamento con lo stato HTTP 301 ”Permanente” con una mappa di riscrittura, può personalizzare le sue traduzioni in situazioni in cui le regole non funzionano bene.

Una volta impostata la regola di base, può modificarla secondo le necessità. L’editor di regole suddivide le cose molto bene

Si inizia con un nome di regola e il modello di URL da abbinare

Da lì, può aggiungere varie condizioni, come ad esempio:

• Una ricerca di una stringa particolare in un parametro URL
• Una variabile d’ambiente del server
• E così via

Può dire che deve corrispondere a tutte o a una qualsiasi delle condizioni. Se le condizioni non sono soddisfatte, la regola non eseguirà la riscrittura

Può anche eseguire sostituzioni sulle variabili del server, il che è ideale per imporre determinati comportamenti

Le variabili del server comprendono un elenco molto ampio di elementi con cui lavorare, comprese le mappe di riscrittura che ha creato

Poi definisce ciò che la regola deve effettivamente fare, ossia eseguire una riscrittura o un reindirizzamento che invierà effettivamente un codice di stato HTTP di reindirizzamento al client per interrogare il nuovo URL

Poi definisce il modello per la riscrittura stessa. Infine, ha alcune opzioni:

• Aggiunta della stringa di richiesta;
• Salvi la richiesta;
• Non esegua altre regole una volta terminato.

3.2 Come posso riscrivere un URL con Apache?

Ecco alcuni passaggi su come definire le regole di riscrittura degli URL con Apache:

Passo 1: installare il server web Apache

Prima di iniziare, si assicuri di avere il pacchetto del server web Apache installato sul suo sistema. Se non è installato, può installarlo con il seguente comando: ”apt-get install apache2 -y”

Una volta installato il pacchetto, avvii il servizio Apache con il seguente comando: ”systemctl start apache2”.

Quindi apra il suo browser web e digiti l’URL http://your-server-ip per verificare il server web Apache

Passo 2: Abilitare mod_rewrite

Per impostazione predefinita, il modulo mod_rewrite è installato con il pacchetto Apache, ma è disattivato. Pertanto, dovrà prima abilitarlo.

Può attivarla con il seguente comando: ”a2enmod rewrite”.

Quindi riavvii il servizio Apache per applicare le modifiche e controlli il modulo Apache mod_rewrite con il seguente comando: apache2ctl -M | grep rewrite_module.

Dovrebbe ottenere il seguente risultato: rewrite_module (shared)

Passo 3: Abilitare i file .htaccess

Può impostare le regole di riscrittura direttamente nel file di configurazione principale di Apache. Tuttavia, si consiglia di scrivere delle regole nel file .htaccess all’interno di ogni sito web.

Per impostazione predefinita, Apache non consente di utilizzare il file .htaccess. Dovrà abilitare il file .htaccess nel file di configurazione del suo host virtuale predefinito.

Per farlo, modifichi il file di configurazione dell’host virtuale predefinito di Apache: nano /etc/apache2/sites-available/000-default.conf.

Aggiunga le seguenti linee prima della linea

Opzioni Indice FollowSymLinks MultiVisioni

Consentire l’annullamento di tutti

Richiedere a tutti di essere concessi

.

Si assicuri di salvare e chiudere il file, quindi riavvii il servizio Apache per applicare le modifiche: systemctl restarts apache2.

Passo 4: Configurare le riscritture degli URL

Per capire come funziona la riscrittura degli URL, creeremo una pagina home.html nella directory principale del documento Apache

Configureremo quindi un URL rewrite di base che accederà alla pagina http://your-server-ip/home e lo convertirà nel percorso della pagina http://your-server-ip/home.html attuale.

Iniziamo creando una pagina home.html:

nano /var/www/html/home.html

Aggiunga il seguente contenuto:

Home

Pagina iniziale

Ecco la mia home page

.

Salvi e chiuda il file quando ha finito.

Successivamente, crei un file .htaccess nella directory principale del sito web per testare il mod_rewrite.

nano /var/www/html/.htaccess

Per prima cosa, aggiunga la seguente riga per abilitare il motore di riscrittura: RewriteEngine enabled.

Quindi aggiunga la seguente regola di riscrittura che reindirizza i visitatori a home.html se richiedono la pagina http://your-server-ip/home: RewriteRule ^home$ home.html [NC].

Salvi e chiuda il file quando ha finito.

Di seguito viene fornita una breve spiegazione della sintassi delle regole di riscrittura:

• ^: corrisponde a qualsiasi testo dopo l’indirizzo IP del server;
• $: indica la fine dell’URL.
• home: corrisponde alla stringa attuale home;
• home.html: definisce il file effettivo a cui il visitatore accede;
• [NC]: questo rende la regola insensibile alle maiuscole e alle minuscole.

Ora può visitare la pagina iniziale all’indirizzo http://your-server-ip/home sul suo browser web. Apache reindirizzerà alla pagina home.html.

3.3. Come fare una riscrittura con nginx

In nginx, la direttiva di riscrittura può essere specificata in uno dei tre contesti: server, location, if.

3.3.1. Esempio di riscrittura Nginx con $1, $2, .

Ecco un esempio di direttiva di riscrittura Nginx: riscrivere ^(/data/.*)/geek/(\w+)\?.*$ $1/linux/$2.html ultimo.

Per esempio :

Url/data/distro/geek/test.php sarà riscritto come url/data/distro/linux/test.html.

In questo esempio, quando richiama l’URL originale con test.php dal browser, questo verrà riscritto in base alla regola di riscrittura di cui sopra e servirà la pagina test.html di /data/distro/linux/

Nella regola di riscrittura precedente :

• $1 e $2 catturano le stringhe appropriate dall’URL originale, che non cambia;
• $1 nella stringa di sostituzione corrisponderà a tutto ciò che si trova all’interno della prima parentesi ( ) nel reg-ex. Nel nostro esempio, $1 è /data/ ;
• Allo stesso modo, $2 corrisponde a tutto ciò che si trova all’interno della seconda parentesi ( ) nel reg-ex. Quindi, $2 è (\w+), ovvero qualsiasi parola che viene dopo il /geek/ nell’URL originale;
• Nel nostro esempio, $2 è un ultimo test. Questo flag farà in modo di smettere di cercare la direttiva di riscrittura nella posizione o nel blocco corrente e di utilizzare l’URL modificato e di cercare una nuova posizione per qualsiasi altra direttiva di riscrittura che corrisponda;
• *$: indica l’estensione nell’URL originale. Si noti che in questo caso l’estensione dell’URL originale sarà sostituita da .html nell’URL riscritto. Quindi, anche se chiama .php nell’URL originale, servirà solo il file .html nell’URL riscritto.

Sebbene le regole di riscrittura di Nginx siano simili a quelle di Apache, ci sono ancora molte differenze nel modo in cui si scrive una regola di riscrittura in Nginx.

3.3.2. Creare un file controllore usando Nginx Rewrite

Utilizzando la riscrittura, può indirizzare molti URL di origine in entrata verso un modello di controller master che servirà queste richieste.

Il seguente esempio di riscrittura lo spiega:

• riscrive ^/linux/(.*)$ /linux.php?distro=$1 ultimo ;

In questo esempio, quando si chiama l’URL thegeekstuff.com/linux/centos, questo verrà riscritto utilizzando la regola precedente e verrà servita la pagina con questo URL riscritto

• thegeekstuff.com/linux.php?distro=centos

Come si può vedere sopra, qualsiasi URL che corrisponde allo schema qui /linux/ nell’URL sarà servito da linux.php, ma l’ultima parte dell’URL originale in arrivo sarà utilizzata come valore per l’argomento distribuzione nel controllore linux.php.

Quindi, la regola di riscrittura di cui sopra trasformerà l’URL in entrata come segue:

• linux/centos diventa linux.php?distro=centos ;
• linux/debian diventa linux.php?distro=debian ;
• linux/redhat diventa linux.php?distro=redhat ;
• ecc.

Come nell’esempio precedente, utilizziamo $1 nella stringa di sostituzione per catturare tutto ciò che si trova all’interno della prima parentesi ( ) nel reg-ex. In questo caso, si tratta dell’ultima parte dell’URL originale in entrata.

Utilizziamo anche l’ultimo flag qui per dire a nginx di smettere di cercare altre direttive di riscrittura nel blocco corrente e di passare alla posizione successiva corrispondente per ulteriori ricerche.

3.3.3. Riscrivere l’indicatore di interruzione nel contesto della posizione

In questo esempio, abbiamo inserito la condizione di riscrittura nella direttiva di localizzazione.

In questo esempio, la direttiva di localizzazione è /data/, che corrisponde anche all’1$ nella stringa di sostituzione riportata di seguito.

dati sulla posizione/ {

riscrive ^(/data/.*)/geek/(\w+)*$1/linux/$2.html break ;

ritorno 403 ;

Ecco cosa sarebbe successo se avesse utilizzato il flag “last” di cui sopra:

• Quindi, se ha scelto ”last” come flag, dopo la riscrittura iniziale dell’URL, Nginx cercherà generalmente la direttiva di riscrittura successiva per il nuovo URL;
• In questo caso, Nginx continuerà a reindirizzare ai dati della stessa posizione e continuerà ad elaborare la stessa regola di riscrittura fino a 10 volte, e alla fine restituirà il codice di errore 500.

3.3.4. Aggiunta di un punto interrogativo alla stringa sostitutiva di Nginx Rewrite

Se una stringa sostitutiva include le nuove parole chiave della query, le parole chiave della query precedente vengono aggiunte dopo di esse

Se non vuole farlo, inserisca un punto interrogativo alla fine di una stringa di sostituzione per evitare di aggiungerla.

Nell’esempio seguente, nella porzione di stringa sostitutiva, non c’è alcun punto interrogativo alla fine. Cioè, nessun punto interrogativo dopo 1 dollaro:

riscrive ^/linux/(.*)$ /linux.php?distro=$1 ultimo ;

Nell’esempio precedente, quando la stringa di sostituzione include gli argomenti della richiesta in arrivo, gli argomenti della richiesta precedente vengono aggiunti dopo di essi.

Quando non vuole che questa aggiunta si verifichi davvero, può avere un risultato alternativo.

Nell’esempio seguente, nella parte della stringa sostitutiva della riscrittura Nginx, può aggiungere (?) alla fine, cioè c’è un punto interrogativo dopo $1

riscrive ^/linux/(.*)$ /linux.php?distro=$1? ultimo;

Nell’esempio precedente, la stringa di sostituzione include gli argomenti della richiesta in arrivo, e poi gli argomenti della richiesta precedente non vengono aggiunti dopo di essi.

3.3.5 ”if” Il contesto e la direttiva di riscrittura

I seguenti esempi illustrano che possiamo utilizzare la riscrittura all’interno della direttiva if.

Può eseguire una riscrittura condizionale basata su un confronto di condizioni if, utilizzando variabili come $schema, $http_host, $http_user_agent, eccetera, come mostrato di seguito:

se ($schema = “http”) {

riscrivere ^ https://www.thegeekstuff.com$uri permanente ;

se ($http_host = thegeekstuff.com) {

riscrivere (.*) https://www.thegeekstuff.com$1 ;

se ($http_user_agent = MSIE) {

riscrive ^(.*)$ /pdf/$1 pausa ;

Si noti anche che esistono modi migliori per ottenere il risultato finale degli esempi precedenti

Gli esempi precedenti sono stati forniti solo per dimostrare che possiamo aggiungere una direttiva di riscrittura all’interno della dichiarazione ”if” nel file di configurazione di nginx.

Tenga presente che può anche impostare il valore dei due parametri seguenti su on o off nel suo file di configurazione di nginx:

nome_server_in_redirect on

port_in_redirect disattivato

3.3.6. Cattura degli hit di riscrittura di Nginx nel file di registro degli errori

Per impostazione predefinita, ogni volta che Nginx esegue una riscrittura di successo, non la registra nel file error.log.

Inizialmente, quando scrive regole di riscrittura complesse, deve assicurarsi che Nginx esegua la riscrittura come richiesto.

Per farlo, deve abilitare il log di riscrittura, che scriverà una voce di log ogni volta che nginx esegue una riscrittura di successo utilizzando una delle direttive di riscrittura nel file di configurazione.

Per fare questo,

• Utilizzi la direttiva rewrite_log e la imposti su on;
• Aggiunga le due righe seguenti al suo nginx default.conf:

notice error_log /var/log/nginx/error.log ;

riscrivere_log a ;

La prima riga indica la posizione del file error_log dove devono essere scritti i messaggi di riscrittura

Si prega di notare che un messaggio di riscrittura è di tipo avviso. Pertanto, deve aggiungere ”nota” alla fine di questa riga, come mostrato sopra.

3.4. Qual è il vero problema delle regole di riscrittura degli URL?

Gli sviluppatori di applicazioni web utilizzano le regole di riscrittura degli URL per nascondere i parametri nella struttura del percorso URL

Questo rende più facile per i motori di ricerca indicizzare tutte le pagine di un sito web, mentre i browser web ricevono l’URL in un formato comprensibile e facile da ricordare per gli utenti.

È importante assicurarsi che queste richieste siano accettate dall’applicazione web e che tutti i parametri URL siano analizzati correttamente

Di seguito sono riassunti i problemi che possono verificarsi quando un software di scansione automatizzata delle vulnerabilità web tenta di analizzare i siti web che utilizzano la tecnologia e le regole di riscrittura degli URL:

3.4.1. I parametri negli URL non vengono analizzati

Un problema comune riscontrato dagli scanner di vulnerabilità web durante la scansione delle applicazioni web che utilizzano la tecnologia di riscrittura degli URL è che gli scanner non sono in grado di identificare i parametri negli URL

Gli scanner presuppongono che gli URL siano directory e non nomi o valori di parametri, e li lasciano senza scansione.

3.4.2. Scansioni di vulnerabilità prolungate

Questo problema può portare a scansioni prolungate e a risultati errati

Ad esempio, se lo scanner di vulnerabilità web analizza un database di strumenti che contiene 100.000 strumenti, poiché lo scanner non è in grado di identificare la presenza di un parametro e di un valore nell’URL, penserà che si tratti di pagine diverse. Quindi cercherà di strisciare e scansionare tutti.

Se i problemi di memoria e altre eccezioni non vengono gestiti correttamente dal suo scanner, questo potrebbe anche far sì che il suo software inizi a bloccarsi e lasciarla senza risultati.

3.4.3. L’impostazione delle regole di riscrittura degli URL è un processo difficile

Poiché la tecnologia di riscrittura degli URL è diventata molto popolare nelle applicazioni web, molti scanner di vulnerabilità web commerciali consentono agli utenti di configurare lo scanner. Questo permette loro di identificare i parametri negli URL e di scansionarli.

Ma anche se gli scanner di vulnerabilità web possono essere configurati per scansionare i siti web utilizzando le regole di riscrittura degli URL, gli utenti possono riscontrare diversi altri problemi, come ad esempio

• La configurazione del supporto per le regole di riscrittura degli URL è molto difficile;
• L’utente deve sapere come scrivere le espressioni regolari;
• L’utente deve avere accesso ai file di configurazione del server web.

Quindi, se non è lo sviluppatore dell’applicazione web stessa o se non ha una conoscenza approfondita dell’applicazione web, è impossibile configurare le regole di riscrittura degli URL sullo scanner

E anche se sa come farlo, la configurazione delle regole di riscrittura è un compito molto difficile e richiede tempo.

3.4.4. Le applicazioni web non vengono scansionate correttamente per le vulnerabilità

Supponendo che lei riesca a configurare le regole di riscrittura degli URL nel suo scanner di vulnerabilità web, ci sono altri problemi.

Esiste una serie di limitazioni nel modo in cui gli scanner analizzano l’applicazione web. Come misura di sicurezza, le applicazioni web non accettano richieste HTTP già “tradotte”

Per impostazione predefinita, le applicazioni web .NET non accettano richieste HTTP

Il problema diventa ancora più importante quando si analizzano le applicazioni web MVC, poiché queste applicazioni utilizzano un approccio diverso alla riscrittura degli URL.

Una volta configurate le regole di riscrittura degli URL nel suo scanner, invia un tipo di richiesta HTTP chiamata richiesta tradotta

Anche se lo scanner di sicurezza delle applicazioni web segnala che la scansione ha avuto successo, la maggior parte delle richieste HTTP viene rifiutata e i parametri URL non vengono analizzati, dando un falso senso di sicurezza.

Conclusione

Notiamo che la riscrittura dell’URL è talvolta essenziale per garantire che il suo indirizzo non dia una cattiva impressione agli utenti di Internet.

È un processo che offre molti vantaggi dal punto di vista della SEO e della credibilità del sito web.

In questo contenuto, abbiamo chiarito il concetto di riscrittura degli URL e lo abbiamo accompagnato con i modi migliori per riscrivere i suoi URL.

La invitiamo a condividere con noi le sue opinioni e altre risorse sul concetto di riscrittura degli URL.