La risposta alla richiesta di verifica preliminare non supera il controllo del controllo accessi

Ricevo questo errore utilizzando ngResource per chiamare un’API REST su Amazon Web Services:

XMLHttpRequest non può caricare http://server.apiurl.com:8000/s/login?login=facebook . La risposta alla richiesta di verifica preliminare non supera il controllo del controllo accessi: Nessuna intestazione ‘Access-Control-Allow-Allow-Origin’ è presente sulla risorsa richiesta. L” http: // localhost ‘ di origine non è quindi consentito l’accesso. Errore 405

Servizio:

socialMarkt.factory('loginService', ['$resource', function($resource){ var apiAddress = "http://server.apiurl.com:8000/s/login/"; return $resource(apiAddress, { login:"facebook", access_token: "@access_token" ,facebook_id: "@facebook_id" }, { getUser: {method:'POST'} }); }]); 

controller:

 [...] loginService.getUser(JSON.stringify(fbObj)), function(data){ console.log(data); }, function(result) { console.error('Error', result.status); } [...] 

Sto usando Chrome e non so cos’altro fare per risolvere questo problema. Ho persino configurato il server per accettare le intestazioni da localhost origine.

    Stai riscontrando problemi CORS.

    Ci sono diversi modi per risolvere questo problema.

    1. Distriggers CORS. Ad esempio: come distriggersre cors in chrome
    2. Usa un plugin per il tuo browser
    3. Utilizzare un proxy come nginx. esempio di come impostare

    Più verbalmente, stai tentando di accedere a api.serverurl.com da localhost. Questa è la definizione esatta della richiesta di dominio incrociato.

    Spegnendolo o spegnendo il tuo lavoro (OK, metti al sicuro la tua sicurezza se visiti altri siti e butti giù la lattina) puoi usare un proxy che fa in modo che il tuo browser pensi che tutte le richieste arrivino dall’host locale quando in realtà hai un server locale che chiama il server remoto.

    così api.serverurl.com potrebbe diventare localhost: 8000 / api e il tuo nginx locale o altro proxy invierà alla destinazione corretta.


    Ora, a grande richiesta, il 100% di informazioni CORS in più …. lo stesso grande gusto!


    E per i downvoters …. bypassare CORS è esattamente ciò che viene mostrato per chi semplicemente apprende il front-end. https://codecraft.tv/courses/angular/http/http-with-promises/

    Il mio “Server API” è un’applicazione PHP, quindi per risolvere questo problema ho trovato la soluzione seguente:

    Posiziona le linee in index.php

     header('Access-Control-Allow-Origin: *'); header('Access-Control-Allow-Methods: GET, POST, PATCH, PUT, DELETE, OPTIONS'); header('Access-Control-Allow-Headers: Origin, Content-Type, X-Auth-Token'); 

    In web API AspNetCore, questo problema è stato risolto aggiungendo “Microsoft.AspNetCore.Cors” (versione 1.1.1) e aggiungendo le modifiche seguenti su Startup.cs.

     public void ConfigureServices(IServiceCollection services) { services.AddCors(options => { options.AddPolicy("AllowAllHeaders", builder => { builder.AllowAnyOrigin() .AllowAnyHeader() .AllowAnyMethod(); }); }); . . . } 

    e

     public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory) { // Shows UseCors with named policy. app.UseCors("AllowAllHeaders"); . . . } 

    e mettendo [EnableCors("AllowAllHeaders")] sul controller.

    JavaScript XMLHttpRequest e Fetch seguono la stessa politica di origine. Quindi, un’applicazione web che utilizza XMLHttpRequest o Fetch poteva solo effettuare richieste HTTP al proprio dominio.

    Fonte: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

    Devi inviare Access-Control-Allow-Origin: * Intestazione HTTP dal lato server.

    Se si utilizza Apache come server HTTP, è ansible aggiungerlo al proprio file di configurazione di Apache in questo modo:

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

    Mod_headers è abilitato di default in Apache, tuttavia, si consiglia di assicurarsi che sia abilitato eseguendo:

      a2enmod headers 

    Se stai scrivendo un’estensione per il cromo

    Devi aggiungere in manifest.json le autorizzazioni per i tuoi domini.

     "permissions": [ "http://example.com/*", "https://example.com/*" ] 

    Per il server di fiaschetta python, è ansible utilizzare il plugin flask-cors per abilitare le richieste tra domini.

    Vedi: https://flask-cors.readthedocs.io/en/latest/

    Se si utilizza il server IIS per caso. puoi impostare sotto le intestazioni nell’opzione delle intestazioni delle richieste HTTP.

     Access-Control-Allow-Origin:* Access-Control-Allow-Methods: 'HEAD, GET, POST, PUT, PATCH, DELETE' Access-Control-Allow-Headers: 'Origin, Content-Type, X-Auth-Token'; 

    con questo tutto post, ecc., funzionerà bene.

    Per coloro che utilizzano Lambda Integrated Proxy con gateway API . È necessario configurare la funzione lambda come se si inviasse le richieste direttamente, il che significa che la funzione dovrebbe configurare correttamente le intestazioni di risposta. (Se si utilizzano funzioni lambda personalizzate, questa sarà gestita dal gateway API.)

     //In your lambda's index.handler(): exports.handler = (event, context, callback) => { //on success: callback(null, { statusCode: 200, headers: { "Access-Control-Allow-Origin" : "*" } } } 

    Nel mio file di configurazione di Apache VirtualHost, ho aggiunto le seguenti righe:

     Header always set Access-Control-Allow-Origin "*" Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT" Header always set Access-Control-Max-Age "1000" Header always set Access-Control-Allow-Headers "x-requested-with, Content-Type, origin, authorization, accept, client-security-token" RewriteEngine On RewriteCond %{REQUEST_METHOD} OPTIONS RewriteRule ^(.*)$ $1 [R=200,L] 

    In PHP puoi aggiungere le intestazioni:

      

    Le distribuzioni standalone di GeoServer includono il server delle applicazioni Jetty. Abilitare la condivisione delle risorse tra origini diverse (CORS) per consentire alle applicazioni JavaScript esterne al proprio dominio di utilizzare GeoServer.

    Decommentare i seguenti e da webapps / geoserver / WEB-INF / web.xml:

       cross-origin org.eclipse.jetty.servlets.CrossOriginFilter   cross-origin /*   

    Penso che disabilitare CORS da Chrome non sia un buon modo , perché se lo stai usando in ionic, sicuramente in Mobile Build il numero aumenterà di nuovo.

    Quindi meglio risolvere nel tuo back-end.

    Prima di tutto nell’intestazione, è necessario impostare

    • intestazione (‘Access-Control-Allow-Origin: *’);
    • header (‘Intestazione set Access-Control-Allow-Headers: “Origine, X-Requested-With, Content-Type, Accept”‘);

    E se l’API si comporta come GET e POST, allora anche Set nella tua intestazione-

    if ($ _SERVER [‘REQUEST_METHOD’] == ‘OPTIONS’) {if (isset ($ _ SERVER [‘HTTP_ACCESS_CONTROL_REQUEST_METHOD’])) intestazione (“Access-Control-Allow-Methods: GET, POST, OPTIONS”);
    if (isset ($ _ SERVER [‘HTTP_ACCESS_CONTROL_REQUEST_HEADERS’])) header (“Access-Control-Allow-Headers:
    {$ _SERVER [‘HTTP_ACCESS_CONTROL_REQUEST_HEADERS’]} “); exit (0);}

    Ho riscontrato questo problema quando il server DNS era impostato su 8.8.8.8 (google). In realtà, il problema era nel router, la mia applicazione ha provato a connettersi con il server tramite Google, non localmente (per il mio caso particolare). Ho rimosso 8.8.8.8 e questo ha risolto il problema. So che questo problema è risolto dalle impostazioni CORS, ma forse qualcuno avrà lo stesso problema di me

    Qualcosa che è molto facile da perdere …

    IN solution explorer, fare clic con il tasto destro del mouse su api-project. Nella finestra delle proprietà impostare ‘Autenticazione anonima’ su Abilitato !!!

    Disabilita la sicurezza di Chrome. Crea un collegamento di Chrome con il tasto destro del mouse -> Proprietà -> destinazione, incolla questo “C: \ Programmi (x86) \ Google \ Chrome \ Application \ chrome.exe” –disable-web-security –user -data-dir = “c: / chromedev”