Ответ на предполетный запрос не проходит проверку контроля доступа

Мой "API-сервер" - это приложение PHP, поэтому для решения этой проблемы я нашел решение ниже:

Поместите строки в 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');

В AspNetCore web api эта проблема исправлена ​​добавлением "Microsoft.AspNetCore.Cors" (версия 1.1.1) и добавлением ниже изменений в Startup.cs.

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

и

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


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

и положив [EnableCors("AllowAllHeaders")] на контроллер.

JavaScript XMLHttpRequest и Fetch следуют политике одного и того же происхождения. Так, веб-приложение, использующее XMLHttpRequest или Fetch, могло только сделать HTTP запросы в свой домен.

Источник: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

Вы должны отправить HTTP-заголовок Access-Control-Allow-Origin: * со своей стороны.

Если вы используете Apache в качестве своего HTTP-сервера, вы можете добавить его в свой конфигурационный файл Apache следующим образом:

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

Mod_headers включен по умолчанию в Apache, однако вы можете убедиться, что он включен при запуске:

 a2enmod headers

Если вы пишете хром-расширение

Вы должны добавить в manifest.json разрешения для вашего домена (ов).

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

Если вы случайно используете сервер IIS. вы можете установить ниже заголовки в опции заголовков 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';

с этим всем сообщением, get и т.д. будет работать нормально.

Для сервера флагов python вы можете использовать плагин-флагов, чтобы разрешать запросы на междоменные запросы.

Смотрите: https://flask-cors.readthedocs.io/en/latest/

Есть некоторые предостережения, когда дело доходит до CORS. Во-первых, он не допускает подстановочные знаки * но не держите меня за это, я его где-то читал, и я не могу найти статью сейчас.

Если вы делаете запросы из другого домена, вам нужно добавить разрешенные заголовки источника. Access-Control-Allow-Origin: www.other.com

Если вы делаете запросы, которые влияют на ресурсы сервера, такие как POST/PUT/PATCH, и если тип mime отличается от следующего application/x-www-form-urlencoded, multipart/form-data или text/plain браузер автоматически сделайте запрос перед полетом OPTIONS для проверки с сервером, если он позволит это.

Таким образом, ваш API/сервер должен обрабатывать эти запросы OPTIONS соответственно, вам нужно ответить соответствующими access control headers а код состояния ответа HTTP должен быть 200.

Заголовки должны быть примерно такими, настраивать их для ваших нужд: Access-Control-Allow-Methods: GET, POST, PUT, PATCH, POST, DELETE, OPTIONS Access-Control-Allow-Headers: Content-Type Access-Control-Max-Age: 86400 Заголовок максимального возраста важен, в моем случае он не будет работать без него, я думаю, браузеру нужна информация о том, как долго "права доступа" действительны.

Кроме того, если вы делаете, например, запрос POST с помощью application/json mime из другого домена, вам также необходимо добавить ранее упомянутый заголовок источника разрешения, поэтому он будет выглядеть так:

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

Когда перед полетом удастся и получит всю необходимую информацию, ваш фактический запрос будет сделан.

Вообще говоря, любые заголовки Access-Control запрашиваются в запросе на первоначальный или предполетный, должны быть указаны в ответе, чтобы он работал.

В документах MDN есть хороший пример в этой ссылке, и вы также должны проверить это сообщение SO

В PHP вы можете добавить заголовки:

<?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: *");
...

Для них используется Lambda Integrated Proxy с API Gateway. Вам необходимо настроить свою лямбда-функцию, как если бы вы отправляли свои запросы непосредственно, то есть функция должна правильно настроить заголовки ответов. (Если вы используете пользовательские лямбда-функции, это будет обрабатываться шлюзом API.)

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

В моем конфигурационном файле Apache VirtualHost я добавил следующие строки:

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]

Наша команда иногда видит это, используя Vue, axios и С# WebApi. Добавление атрибута маршрута в конечную точку, к которой вы пытаетесь попасть, исправляет его для нас.

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

Чтобы устранить проблемы перекрестных исходных запросов в приложении Node JS:

npm i cors

И просто добавьте строки ниже в app.js

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

Очень часто причиной этой ошибки может быть то, что API-интерфейс хоста сопоставил запрос с методом http (например, PUT), и клиент API вызывает API с использованием другого метода http (например, POST или GET)

Я использую AWS SDK для загрузки, потратив некоторое время на поиск в Интернете, я наткнулся на эту тему. благодаря @lsimoneau 45581857 выясняется, что происходит то же самое. Я просто указал URL-адрес своей просьбы на регион, добавив параметр region, и это сработало.

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

Отдельные дистрибутивы GeoServer включают сервер приложений Jetty. Включить совместное использование ресурсов (CORS), чтобы позволить приложениям JavaScript за пределами вашего собственного домена использовать GeoServer.

Раскомментируйте следующие <filter> и <filter-mapping> из 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>

Я столкнулся с этой проблемой, когда DNS-сервер был установлен в 8.8.8.8 (google). На самом деле проблема была в маршрутизаторе, мое приложение пыталось подключиться к серверу через Google, а не локально (для моего конкретного случая). Я удалил 8.8.8.8, и это решило проблему. Я знаю, что эти проблемы решаются с помощью настроек CORS, но, возможно, у кого-то будет такая же проблема, как у меня.

Я считаю, что отключение CORS от Chrome - это не очень хороший способ, потому что, если вы используете его в ионном режиме, в Mobile Build проблема снова будет повышена.

Так лучше исправить в вашем Backend.

Прежде всего в заголовке заголовка, вам нужно set-

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

И если API ведет себя как GET и POST, то и Set в вашем header-

if ($ _SERVER ['REQUEST_METHOD'] == 'OPTIONS') {if (isset ($ _ SERVER ['HTTP_ACCESS_CONTROL_REQUEST_METHOD'])) заголовок ("Access-Control-Allow-Methods: GET, POST, OPTIONS");
if (isset($_SERVER['HTTP_ACCESS_CONTROL_REQUEST_HEADERS'])) header("Access-Control-Allow-Headers: if (isset ($ _ SERVER ['HTTP_ACCESS_CONTROL_REQUEST_HEADERS'])) заголовок ("Access-Control-Allow-Headers:
{$_SERVER['HTTP_ACCESS_CONTROL_REQUEST_HEADERS']}"); exit(0); } {$ _SERVER ['HTTP_ACCESS_CONTROL_REQUEST_HEADERS'}} "); exit (0);}

То, что очень легко пропустить...

В проводнике решений, щелкните правой кнопкой мыши api-project. В окне свойств установите "Анонимная аутентификация" на "Включено".

Отключите chrome security.Create chrome shortcut right click → properties → target, вставьте это "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-web-security --user -data-DIR = "C: /chromedev"