Il set di intestazione Access-Control-Allow-Origin in .htaccess non funziona

Non riesco a capire perché le mie impostazioni dell’intestazione .htaccess non funzionino.

Il mio contenuto del file .htaccess :

 Header set Access-Control-Allow-Origin * Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT" Header always set Access-Control-Allow-Headers "*" RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ index.php [QSA,L] 

Ma quando rimuovo le Header e le aggiungo in index.php tutto funziona correttamente.

 header("Access-Control-Allow-Origin: *"); header("Access-Control-Allow-Methods: PUT, GET, POST, DELETE, OPTIONS"); header("Access-Control-Allow-Headers: *"); 

Cosa mi manca?

    Questo dovrebbe funzionare:

     Header add Access-Control-Allow-Origin "*" Header add Access-Control-Allow-Headers "origin, x-requested-with, content-type" Header add Access-Control-Allow-Methods "PUT, GET, POST, DELETE, OPTIONS" 

    Solo per la cronaca, stavo correndo nello stesso identico problema e nessuna delle risposte funzionava.

    Ho usato uno strumento per il controllo delle intestazioni: http://www.webconfs.com/http-header-check.php

    Stavo testando con il mio IP ( http://192.0.2.1/upload ) e ciò che è tornato è stato il seguente:

     HTTP/1.1 301 Moved Permanently => Date => Sat, 10 Jan 2015 04:03:35 GMT Server => Apache/2.2.21 (Win32) mod_ssl/2.2.21 OpenSSL/1.0.0e PHP/5.3.8 mod_perl/2.0.4 Perl/v5.10.1 Location => http://192.0.2.1/upload/ Content-Length => 380 Connection => close Content-Type => text/html; charset=iso-8859-1 

    C’è stato un evento di reindirizzamento e la richiesta AJAX non ha rispettato / seguito i reindirizzamenti.

    Si è rivelata la barra mancante alla fine del dominio ( http://192.0.2.1/upload / )

    Ho provato di nuovo con la barra alla fine e ho ottenuto questo sotto. Aggiunta una barra nello script e ora funzionava.

     HTTP/1.1 200 OK => Date => Sat, 10 Jan 2015 04:03:53 GMT Server => Apache/2.2.21 (Win32) mod_ssl/2.2.21 OpenSSL/1.0.0e PHP/5.3.8 mod_perl/2.0.4 Perl/v5.10.1 X-Powered-By => PHP/5.3.8 Access-Control-Allow-Origin => * Access-Control-Allow-Methods => PUT, GET, POST, DELETE, OPTIONS Access-Control-Allow-Headers => * Content-Length => 1435 Connection => close Content-Type => text/html 

    Utilizzare questo strumento per verificare se le intestazioni sono buone e per risolvere ciò che sta accadendo.

    Ho un hosting condiviso su GoDaddy. Avevo anche bisogno di una risposta a questa domanda, e dopo aver cercato in giro ho scoperto che è ansible.

    Ho scritto un file .htaccess, lo metto nella stessa cartella della mia pagina di azione. Ecco i contenuti del file .htaccess:

     Header add Access-Control-Allow-Origin "*" Header add Access-Control-Allow-Headers "origin, x-requested-with, content-type" Header add Access-Control-Allow-Methods "PUT, GET, POST, DELETE, OPTIONS" 

    Ecco la mia chiamata Ajax:

      $.ajax({ url: 'http://www.mydomain.com/myactionpagefolder/gbactionpage.php', //server script to process data type: 'POST', xhr: function() { // custom xhr myXhr = $.ajaxSettings.xhr(); if(myXhr.upload){ // check if upload property exists myXhr.upload.addEventListener('progress',progressHandlingFunction, false); // for handling the progress of the upload } return myXhr; }, //Ajax events beforeSend: beforeSendHandler, success: completeHandler, error: errorHandler, // Form data data: formData, //Options to tell JQuery not to process data or worry about content-type cache: false, contentType: false, processData: false }); 

    Vedi questo articolo per riferimento:

    Il set di intestazione Access-Control-Allow-Origin in .htaccess non funziona

    Ho triggersto le intestazioni del modulo a2enmod delle intestazioni del modulo Apache e il problema è stato risolto.

    Stai attento a:

      Header add Access-Control-Allow-Origin "*" 

    Non è affatto giudizioso garantire l’accesso a tutti. È preferibile consentire solo un elenco di host attendibili …

     Header add Access-Control-Allow-Origin "http://aaa.example" Header add Access-Control-Allow-Origin "http://bbb.example" Header add Access-Control-Allow-Origin "http://ccc.example" 

    Saluti,

    Prova questo nel .htaccess della cartella radice esterna

      Header set Access-Control-Allow-Origin "*"  

    Fai attenzione a: Intestazione aggiungi Access-Control-Allow-Origin “*” Non è affatto giudizioso garantire l’accesso a tutti. Penso che dovresti utente:

      Header set Access-Control-Allow-Origin "http://example.com"  

    Ho fatto +1 alla risposta di Miro per il link al sito di header-checker http://www.webconfs.com/http-header-check.php . Viene visualizzato un annuncio odioso ogni volta che lo si utilizza, ma è, tuttavia, molto utile per verificare la presenza dell’intestazione Access-Control-Allow-Origin.

    Sto leggendo un file .json dal javascript sulla mia pagina web. Ho scoperto che l’aggiunta di quanto segue al mio file .htaccess ha risolto il problema durante la visualizzazione della mia pagina Web in IE 11 (versione 11.447.14393.0):

       Header set Access-Control-Allow-Origin "*"   

    Ho anche aggiunto quanto segue a /etc/httpd.conf (file di configurazione di Apache):

     AllowOverride All 

    Il sito header-checker ha verificato che l’intestazione Access-Control-Allow-Origin viene ora inviata (grazie, Miro!).

    Tuttavia, Firefox 50.0.2, Opera 41.0.2353.69 e Edge 38.14393.0.0 prelevano comunque il file, anche senza l’intestazione Access-Control-Allow-Origin. (Nota: potrebbero controllare gli indirizzi IP, poiché i due domini che stavo utilizzando sono entrambi ospitati sullo stesso server, allo stesso indirizzo IPv4).

    Tuttavia, Chrome 54.0.2840.99 m (64-bit) ignora l’intestazione Access-Control-Allow-Origin e fallisce comunque, riportando erroneamente:

    Nessuna intestazione ‘Access-Control-Allow-Origin’ è presente sulla risorsa richiesta. L’origine ‘ {mydomain} ‘ non è quindi consentita l’accesso.

    Penso che questa debba essere una sorta di “prima”. IE funziona correttamente; Chrome, Firefox, Opera e Edge sono tutti buggati; e Chrome è il peggiore . Non è esattamente l’opposto del solito caso?

    Dopo aver trascorso una mezza giornata senza nulla a lavorare. Utilizzando un servizio di verifica dell’intestazione, però, tutto funzionava. Il firewall al lavoro li stava spogliando