Ajax Web Service Call - No 'Access-Control-Allow-Origin' intestazione è presente

Question

Heyya,

So che questo problema è stato fatto prima e ho letto ogni singola risposta di ogni singola domanda qui, ma ancora non sembra che il mio progetto funzioni correttamente. Il mio scenario è un po 'diverso rispetto ad altre domande, non so se questo faccia qualche differenza, ma qui andiamo.

Ho un progetto fatto di servizi web. I servizi da soli funzionano bene, non ci sono problemi con questo. E c'è un altro progetto che gestisce l'interfaccia utente delle cose e chiama questi servizi tramite jquery ajax. Ha funzionato bene perché non ho ancora testato questo caso su Google Chrome. Tutto funziona perfettamente su Internet Explorer.

Ora; la mia applicazione di servizio Web viene eseguita sulla porta 40000 (localhost: 40000) e il progetto dell'interfaccia utente viene eseguito su un'altra porta casuale ma ancora nell'host locale. Come ho detto, le mie chiamate ajax ecc funzionano perfettamente su Internet Explorer ma quando si tratta di Google Chrome fallisce. La console mostra il seguente errore:

XMLHttpRequest cannot load http://127.0.0.1:40000/abc.asmx/TheMethodName. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:17256' is therefore not allowed access. The response had HTTP status code 400. 

Tra l'altro, è stato come "localhost: 40000" prima così alcuni post su internet ha suggerito che dovrei cambiare a un indirizzo IP invece di localhost.

In ogni caso, ho anche modificato il mio file web.config sul mio progetto di servizio web e ha aggiunto il seguente (che non ha alcun senso)

<system.serviceModel> 
    <bindings> 
    <webHttpBinding> 
     <binding name="crossDomain" crossDomainScriptAccessEnabled="true"> 
     </binding> 
    </webHttpBinding> 
    </bindings> 

    <behaviors> 

    <serviceBehaviors> 
     <behavior> 
     <serviceMetadata httpGetEnabled="true" /> 
     <serviceDebug includeExceptionDetailInFaults="false" /> 
     </behavior> 
    </serviceBehaviors> 

    </behaviors> 

    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" /> 
</system.serviceModel> 


<system.webServer> 
    <modules runAllManagedModulesForAllRequests="true" /> 
    <httpProtocol> 
    <customHeaders> 
     <add name="Access-Control-Allow-Origin" value="http://localhost:17256" /> 
     <add name="Access-Control-Allow-Origin" value="*" /> 
     <add name="Access-Control-Allow-Methods" value="GET, POST, OPTIONS" /> 
     <add name="Access-Control-Allow-Headers" value="Origin, X-Requested-With, Content-Type, Accept" /> 
     <add name="Access-Control-Max-Age" value="1728000" /> 

    </customHeaders> 
    </httpProtocol> 
</system.webServer> 

BTW, se uso la prima riga: si fallisce completamente e dice che i messaggi dell'intestazione di risposta non corrispondono e non riesco neanche a iniziare il richiamo del servizio.

E sì, ho anche modificato il mio chiamata ajax, aggiunto il seguente parametro:

crossDomain: true, 

Ora, che cosa mi manca qui? Sono stato su questo per giorni e sto per perdere la testa :) È troppo tardi per cambiare l'intera struttura del progetto (servizio - stile dell'interfaccia utente intendo) poiché sono stati scritti un sacco di codice per i servizi e Progetti di interfaccia utente Per favore aiutami Sono disperato! :)

Acclamazioni

---

Edit:

Così si scopre che ho bisogno di usare JSONP, non JSON - dal momento che non venga bloccato con cosa Access Control, che va bene . Posso convertire le mie chiamate Ajax in quelle JSONP. Ma ho bisogno di un altro aiuto :)

Ho scritto un metodo globale Ajax che viene chiamato da ogni operazione su pagine separate e funziona come fascino (di nuovo su Internet Explorer ovviamente). Ora cosa dovrei fare per convertire questa funzione wrapper in qualcosa di jsonp?

function RemoteCall(WebService, RemoteMethod, RemoteParameters, callbackResult) { 

if (RemoteParameters == null || RemoteParameters == "") { 
    RemoteParameters = "{ }"; 
} 

var remoteCall = $.ajax({ 
    type: "POST", 
    url: ProvideService(WebService, RemoteMethod), 
    data: RemoteParameters, 
    contentType: ajaxContentType, 
    dataType: ajaxDataType, 
    async: true, 
    crossDomain: true, 
    success: function (msg) { 
     msg.header("Access-Control-Allow-Origin", "*"); 
     callbackResult(msg.d); 
    }, 
    error: function (xhr, ajaxOptions, thrownError) { 
     callbackResult(xhr.status + '\r\n' + thrownError + '\r\n' + xhr.responseText); 
    } 
}); 

}

ho visto alcuni post che avrei dovuto aggiungere una proprietà come jsonp: 'jsonp_callback' con il metodo di callback (questo è dove sono confuso). Che dire di questo?

Un'altra cosa; Mi hanno inviato i miei parametri JSON come un testo in una variabile come

var jSONParams = '{ UserID: "1", EmailAddress: "a@b.com" }'; 

Devo continuare a inviare questo come lo stesso formato o dovrebbe essere convertito in una sorta di oggetto JSON o qualcosa del genere?

BTW: la mia funzione ajax globale è in un file JS completamente separato - non so se si fa alcuna differenza se ...

Acclamazioni

Answer 1

Grazie a tutti per le vostre risposte;

Ho trovato la soluzione al mio problema. Sembra che non abbia prestato molta attenzione al messaggio di errore :)

Dopo aver aggiunto l'intestazione Access-Control-Allow-Origin nel mio file web.config, si scopre che ho iniziato a ottenere un altro errore, che era intestazioni di tipo di contenuto, mancava l'intestazione e ho pensato che stavo ancora ricevendo l'errore CORS.

Quindi, aggiungendo la definizione <add name="Access-Control-Allow-Origin" value="*" /> nel mio web.config in realtà ho risolto il mio problema di origine incrociata in primo luogo! E ho anche testato per consentire domini specifici o richieste da porte con la seguente voce di intestazione web.config e ha funzionato anche come fascino - dal momento che penso che sia la migliore opzione da utilizzare dal momento che non pubblicherò i miei servizi pubblicamente.

<add name="Access-Control-Allow-Origin" value="http://localhost:17256" /> 

Saluti a tutti, problema risolto :)

Answer 2

Benvenuti nella terra, non in modo fresco di emissione CORS nel browserland, ho le seguenti raccomandazioni:

1. Se forse è possibile ospitare il webservice e la parte di interfaccia utente sulla stessa porta, Creazione di progetti e rendere il vostro webservice e dell'interfaccia utente sottoprogetti che poi sarebbe facilmente fare farla franca con questo.
2. Se i servizi Web rispondono in JSON, considerare l'utilizzo di JSONP, è sempre consigliabile avere un supporto JSONP per il servizio web.

Spero che aiuta

saluti, Arif Imran

Answer 3

io preferisco per consentire solo CORS che cambiare tutta la vostra chiamata AJAX.

Provate a modificare il web.config per il webservice per aggiungere ancora la seguente riga?

<system.webServer> 
    <httpProtocol> 
     <customHeaders> 

      <add name="Access-Control-Allow-Origin" value="*" /> 
     </customHeaders> 
    </httpProtocol> 

controllare anche questa domanda per se CORS/JSONP è meglio per voi So, JSONP or CORS?

Answer 4

la chiave per risolvere gli errori CORS sta prestando attenzione alle intestazioni nella risposta del server (s). È necessario scaricare un monitor del traffico http come Fiddler per esaminare queste intestazioni. Quindi, puoi usarlo in combinazione con gli errori della console del browser per capire esattamente cosa non va.

Ecco cosa un tipico successo 200 OK risposta/CORS assomiglia (presa direttamente da Fiddler):

HTTP/1.1 200 OK 
Cache-Control: no-cache 
Pragma: no-cache 
Content-Type: application/json; charset=utf-8 
Expires: -1 
Vary: Accept-Encoding 
Server: Microsoft-IIS/7.5 
Access-Control-Allow-Origin: http://localhost:1234 
Access-Control-Allow-Credentials: true 
Access-Control-Allow-Methods: GET,POST,OPTIONS 
X-AspNet-Version: 4.0.30319 
X-UA-Compatible: IE=edge 
Persistent-Auth: false 
WWW-Authenticate: Negotiate oYG2MIGzoAMKAQChCwYJKoZIgvcSAQIC...etc. 
Date: Fri, 08 May 2015 01:14:37 GMT 
Connection: close 
Content-Length: 4711 

...response body etc. etc. 

Nel caso in cui che stai ricevendo il No 'Access-Control-Allow-Origin' header is present on the requested resource, l'intestazione è mancante dalla risposta o essere consegnato in un modo che viola l'implementazione di Chrome delle specifiche W3C.

Osservando il file web.config, sono disposto a scommettere sul suo secondo. Ad esempio, questo è un controllo di accesso valide consentono l'intestazione di origine con più voci:

Access-Control-Allow-Origin: http://domain1.com,http://domain2.com 

mentre il modo in cui il tratto intestazioni web.config è configurato consegnerà più voci, che è generalmente valida

Access-Control-Allow-Origin: http://localhost:17256 
Access-Control-Allow-Origin: * 

...in particolare in scenari in cui le intestazioni di autenticazione e le credenziali Access-Control-Allow-Credentials vengono passate agli endpoint protetti: