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:

Ads: scopri Keliweb ,il servizio di hosting italiano
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:

Ti potrebbe interessare:  Carta d'identità elettronica: cos'è, come richiederla e cosa farci

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.

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

(fonte)



Questo blog pubblica contenuti ed offre servizi free da 11 anni. – Leggi un altro articolo a caso – Per informazioni contattaci
5/5 (1)

Ti sembra utile o interessante? Vota e fammelo sapere.

Come e perchè limitare le richieste CORS (Cross-Origin Resource Sharing)
cors header JSON
Torna su