La respuesta a la solicitud de verificación previa no pasa la verificación de control de acceso

Recibo este error usando ngResource para llamar a una API REST en Amazon Web Services:

XMLHttpRequest no puede cargar http://server.apiurl.com:8000/s/login?login=facebook . La respuesta a la solicitud de verificación previa no pasa la verificación de control de acceso: no hay encabezado 'Access-Control-Allow-Origin' en el recurso solicitado. Por lo tanto, el origen ' http: // localhost ' no tiene acceso permitido. Error 405

Servicio:

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'}
            });
}]);

Controlador:

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

Estoy usando Chrome, y no sé qué más hacer para solucionar este problema. Incluso he configurado el servidor para aceptar encabezados de origen localhost.

Estás teniendo problemas con CORS.

Hay varias formas de solucionar / solucionar esto.

1. Apaga CORS. Por ejemplo: cómo desactivar cors en cromo
2. Use un complemento para su navegador
3. Use un proxy como nginx. ejemplo de cómo configurar
4. Realice la configuración necesaria para su servidor. Esto es más un factor del servidor web que ha cargado en su instancia EC2 (suponiendo que esto es lo que quiere decir con "servicio web de Amazon"). Para su servidor específico, puede consultar el sitio web enable CORS.

De manera más vergonzosa, está intentando acceder a api.serverurl.com desde localhost. Esta es la definición exacta de solicitud de dominio cruzado.

Al apagarlo solo para hacer su trabajo (OK, ponga poca seguridad para usted si visita otros sitios y simplemente tira la lata en el camino) puede usar un proxy que hace que su navegador piense que todas las solicitudes provienen del host local cuando realmente tienes un servidor local que luego llama al servidor remoto.

entonces api.serverurl.com podría convertirse en localhost: 8000 / api y su nginx local u otro proxy se enviarán al destino correcto.

Ahora por demanda popular, 100% más información CORS ... ¡el mismo gran sabor!

Y para los que votan a favor ... pasar por alto CORS es exactamente lo que se muestra para aquellos que simplemente están aprendiendo el front-end. https://codecraft.tv/courses/angular/http/http-with-promises/

Mi "Servidor API" es una aplicación PHP, así que para resolver este problema encontré la siguiente solución para trabajar:

Coloque las líneas en 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');

En la API web de AspNetCore, este problema se solucionó agregando "Microsoft.AspNetCore.Cors" (ver 1.1.1) y agregando los siguientes cambios en Startup.cs.

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

y

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{


    // Shows UseCors with named policy.
    app.UseCors("AllowAllHeaders");
    .
    .
    .
}

y poniéndose [EnableCors("AllowAllHeaders")]el controlador.

Hay algunas advertencias cuando se trata de CORS. Primero, no permite comodines, *pero no me detenga en este, lo he leído en alguna parte y no puedo encontrar el artículo ahora.

Si realiza solicitudes desde un dominio diferente, debe agregar los encabezados de origen permitidos.

 Access-Control-Allow-Origin: www.other.com 

Si va a realizar peticiones que afectan a los recursos del servidor como de POST / PUT / PATCH, y si el tipo MIME es diferente del siguiente application/x-www-form-urlencoded, multipart/form-datao text/plainel navegador automáticamente hará una OPCIONES prevuelos solicitan comprobar con el servidor si lo permitiría .

Por lo tanto, su API / servidor debe manejar estas solicitudes de OPCIONES en consecuencia, debe responder con el apropiado access control headersy el código de estado de respuesta http debe ser 200.

Los encabezados deben ser algo como esto, ajústelos según sus necesidades:

   Access-Control-Allow-Methods: GET, POST, PUT, PATCH, POST, DELETE, OPTIONS
   Access-Control-Allow-Headers: Content-Type
   Access-Control-Max-Age: 86400

El encabezado max-age es importante, en mi caso, no funcionaría sin él, supongo que el navegador necesita la información durante cuánto tiempo son válidos los "derechos de acceso".

Además, si está haciendo, por ejemplo, una POSTsolicitud con application/jsonmime desde un dominio diferente, también debe agregar el encabezado de origen de permiso mencionado anteriormente, para que se vea así:

   Access-Control-Allow-Origin: www.other.com 
   Access-Control-Allow-Methods: GET, POST, PUT, PATCH, POST, DELETE, OPTIONS
   Access-Control-Allow-Headers: Content-Type
   Access-Control-Max-Age: 86400

Cuando el pre-vuelo tenga éxito y obtenga toda la información necesaria, se realizará su solicitud real.

En términos generales, cualquier Access-Controlencabezado que se solicite en la solicitud inicial o previa al vuelo, se debe dar en la respuesta para que funcione.

Hay un buen ejemplo en los documentos de MDN aquí en este enlace , y también debe consultar esta publicación SO

JavaScript XMLHttpRequest y Fetch siguen la política del mismo origen. Por lo tanto, una aplicación web que utiliza XMLHttpRequest o Fetch solo puede realizar solicitudes HTTP a su propio dominio.

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

Debe enviar el encabezado HTTP Access-Control-Allow-Origin: * desde el lado del servidor.

Si está utilizando Apache como su servidor HTTP, puede agregarlo a su archivo de configuración de Apache de esta manera:

<IfModule mod_headers.c>
    Header set Access-Control-Allow-Origin "*"
</IfModule>

Mod_headers está habilitado de forma predeterminada en Apache, sin embargo, es posible que desee asegurarse de que esté habilitado ejecutando:

 a2enmod headers

Si estás escribiendo una extensión de Chrome

Debe agregar manifest.jsonlos permisos para sus dominios.

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

Si está utilizando el servidor IIS por casualidad. puede establecer debajo de los encabezados en la opción de encabezados de solicitud 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 esto todo post, get etc., funcionará bien.

Para el servidor de matraz de Python, puede usar el complemento matraz-cors para habilitar las solicitudes de dominio cruzado.

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

En PHP puedes agregar los encabezados:

<?php
header ("Access-Control-Allow-Origin: *");
header ("Access-Control-Expose-Headers: Content-Length, X-JSON");
header ("Access-Control-Allow-Methods: GET, POST, PATCH, PUT, DELETE, OPTIONS");
header ("Access-Control-Allow-Headers: *");
...

Para solucionar problemas de solicitudes de origen cruzado en una aplicación Node JS:

npm i cors

Y simplemente agregue las líneas de abajo a la app.js

let cors = require('cors')
app.use(cors())

En mi archivo de configuración de Apache VirtualHost, he agregado las siguientes líneas:

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]

Para aquellos que usan Lambda Integrated Proxy con API Gateway . Debe configurar su función lambda como si estuviera enviando sus solicitudes directamente, lo que significa que la función debe configurar los encabezados de respuesta correctamente. (Si está utilizando funciones lambda personalizadas, esto será manejado por API Gateway).

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

Creo que deshabilitar CORS de Chrome no es una buena manera , porque si lo está utilizando en iónico, ciertamente en Mobile Build, el problema volverá a surgir.

Así que mejor arreglarlo en tu backend.

En primer lugar, en el encabezado, debe establecer

• encabezado ('Access-Control-Allow-Origin: *');
• header ('Conjunto de encabezado Access-Control-Allow-Headers: "Origin, X-Requested-With, Content-Type, Accept"');

Y si la API se comporta como GET y POST, ambos también se configuran en el encabezado:

if ($ _SERVER ['REQUEST_METHOD'] == 'OPTIONS') {if (isset ($ _ SERVER ['HTTP_ACCESS_CONTROL_REQUEST_METHOD'])) header ("Access-Control-Allow-Methods: GET, POST, OPTIONS");
if (isset ($ _ SERVER ['HTTP_ACCESS_CONTROL_REQUEST_HEADERS'])) encabezado ("Access-Control-Allow-Headers:
{$ _SERVER ['HTTP_ACCESS_CONTROL_REQUEST_HEADERS']}"); salida (0); }

Una causa muy común de este error podría ser que la API del host había asignado la solicitud a un método http (por ejemplo, PUT) y el cliente API está llamando a la API utilizando un método http diferente (por ejemplo, POST o GET)

Nuestro equipo ocasionalmente ve esto usando Vue, axios y un C # WebApi. Agregar un atributo de ruta en el punto final que está tratando de alcanzar nos lo arregla.

[Route("ControllerName/Endpoint")]
[HttpOptions, HttpPost]
public IHttpActionResult Endpoint() { }

Me he enfrentado a este problema cuando el servidor DNS se configuró en 8.8.8.8 (google's). En realidad, el problema estaba en el enrutador, mi aplicación intentó conectarse con el servidor a través de google, no localmente (para mi caso particular). He eliminado 8.8.8.8 y esto resolvió el problema. Sé que estos problemas se resolvieron mediante la configuración de CORS, pero tal vez alguien tenga el mismo problema que yo

Estoy usando AWS sdk para cargas, después de pasar un tiempo buscando en línea me topé con este hilo. gracias a @lsimoneau 45581857 resulta que exactamente lo mismo estaba sucediendo. Simplemente apunté mi URL de solicitud a la región en mi cubo adjuntando la opción de región y funcionó.

 const s3 = new AWS.S3({
 accessKeyId: config.awsAccessKeyID,
 secretAccessKey: config.awsSecretAccessKey,
 region: 'eu-west-2'  // add region here });

Las distribuciones independientes de GeoServer incluyen el servidor de aplicaciones Jetty. Habilite el uso compartido de recursos de origen cruzado (CORS) para permitir que las aplicaciones de JavaScript fuera de su propio dominio utilicen GeoServer.

Descomente lo siguiente <filter>y <filter-mapping>de webapps / geoserver / WEB-INF / web.xml:

<web-app>
  <filter>
      <filter-name>cross-origin</filter-name>
      <filter-class>org.eclipse.jetty.servlets.CrossOriginFilter</filter-class>
  </filter>
  <filter-mapping>
      <filter-name>cross-origin</filter-name>
      <url-pattern>/*</url-pattern>
  </filter-mapping>
</web-app>

Es fácil resolver este problema con solo unos pocos pasos fácilmente, sin preocuparse por nada. Amablemente, siga los pasos para resolverlo.

1. abierto ( https://www.npmjs.com/package/cors#enabling-cors-pre-flight )
2. vaya a la instalación y copie el comando npm install cors para instalar a través del terminal de nodo
3. vaya a Uso simple (Habilitar todas las solicitudes CORS) desplazándose. a continuación, copie y pegue la declaración completa en su proyecto y ejecútelo ... eso funcionará con seguridad ... copie el código de comentario y péguelo en su app.js o en cualquier otro proyecte y pruebe ... esto funcionará. Esto desbloqueará cada recurso compartido de origen cruzado ... para que podamos cambiar entre los servicios para su uso

Algo que es muy fácil pasar por alto ...

En el explorador de soluciones, haga clic con el botón derecho en api-project. En la ventana de propiedades, configure 'Autenticación anónima' en Activado.

Deshabilite la seguridad de Chrome. Cree un acceso directo de Chrome, haga clic con el botón derecho -> propiedades -> destino, pegue este "C: \ Archivos de programa (x86) \ Google \ Chrome \ Application \ chrome.exe" --disable-web-security --user -data-dir = "c: / chromedev"