Come e perchè limitare le richieste CORS (Cross-Origin Resource Sharing)

Nell’ambito delle chiamate HTTPS o request, occupano un posto speciale quelle che sono definite come Cross-Origin Resource Sharing (CORS), e che vanno in genere evitate per non avere problemi di compatibilità con i propri siti o app. Le richieste CORS sono un meccanismo basato su header HTTP che permette, di fatto, a un server di indicare qualsiasi origin (quindi un URL composto da dominio, schema o porta anche diverse da quelle su cui sta lavorando), e che potrebbe essere utilizzata per caricare risorse di vario genere (dati JSON, XML, ecc.).

Un esempio pratico di CORS

Ammettiamo di avere un sito, per esempio il nostro (trovalost.it), e di aver realizzato per lo stesso una API che possa essere richiamata mediante il sottodominio api.trovalost.it. Questa scelta garantisce di mantenere la separazione tra i due domini e i due contesti (web service e web), e in genere è cosa buona nonchè pratica corretta. Essendo una richiesta a livello di header HTTP, essa potrà funzionare in modo corretto soltanto se viene verificata la pre-condizione per eseguire il CORS, visto che si tratta di due domini diversi, cosa che viene checkata controllando il valore associato all’header HTTP dal nome:

Access-Control-Allow-Origin

e che può essere inquadrata tecnicamente studiando le caratteristiche delle request in termini di same site, same origin. Questa forma di dialogo preliminare tra API e browser, di fatto, è indispensabile perchè api.trovalost.it suggerisce uno schema di URI differente da quello del dominio originale, e anche la porta ed il protocollo potrebbero essere diversi.

Se quindi il sito web all’indirizzo https://trovalost.it/ volesse prelevare dei dati interrogando un web service presente su https://api.trovalost.it/ dopo eventuale autenticazione con chiave di accesso, potrebbe idealmente procedere come segue:

var url = "https://api.trovalost.it/?key=12345&data=about:test";
fetch(url).then(success, failure)

Per fare corretto uso del protocollo CORS, l’origine valida da parte del dominio su cui gira la API dovrà essere esplicitamente aggiunto all’header HTTP.

Origin: https://api.trovalost.it

verificando, prima di inoltrare la richiesta, l’impostazione corretta del valoreAccess-Control-Allow-Origin, e lanciando la API solo in quest’ultimo caso. In genere le richieste CORS fallite possono generare un errore lato client di classe 4xx come un 404 not found, 403 forbidden e così via. Su WordPress la diagnostica di errore è tipicamente legata ad una notifica del tipo:

SMSHosting Usa il codice PROMO per uno sconto sul primo acquisto: PRT96919

Cross-Origin Request Blocked

il che vuol dire che stiamo provando a interrogare una risorsa che il sistema non permette di caricare (cosa che viene a volte notificata lato frontend col messaggio CORS header ‘Access-Control-Allow-Origin’ missing). Se state usando un plugin di cache, assicuratevi di abilitare gli ETag e Last Modified header, disabilitando se necessario la modalità compatibilità (Compatibility mode). In altri casi, invece, può essere utile intervenire sulle direttive del file HTACCESS.

SMSHosting Usa il codice PROMO per uno sconto sul primo acquisto: PRT96919

Potete provare in alternative a implementare la soluzione, mediante plugin personalizzato, proposta in questo articolo.

(fonte)


Questo articolo contiene 473 parole – Questo blog esiste da 3.646 giorni.
5/5 (1)

Che te ne pare?

Grazie per aver letto Come e perchè limitare le richieste CORS (Cross-Origin Resource Sharing) di Max Headroom su Trovalost.it
Come e perchè limitare le richieste CORS (Cross-Origin Resource Sharing) (Guide, Assistenza Tecnica, Guide per la configurazione di WordPress, Guide PHP, Internet)

Articoli più letti su questi argomenti:

Seguici su Telegram: @trovalost