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.).
PRT96919
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:
Cross-Origin Request Blocked
PRT96919
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.
PRT96919
(fonte)
Tutorial, approfondimenti tematici e notizie in ambito tecnologico. Questo articolo non riporta necessariamente pareri o endorsement da parte del proprietario del sito stesso. Per contatti clicca qui
PRT96919
