В запрашиваемом ресурсе отсутствует заголовок "Access-Control-Allow-Origin" - при попытке получить данные из REST API

Я пытаюсь получить некоторые данные из REST API HP Alm. Это работает довольно хорошо с небольшим скриптом curl - я получаю свои данные.

Теперь, делая это с JavaScript, выборка и ES6 (более или менее) кажутся более серьезной проблемой. Я продолжаю получать это сообщение об ошибке:

Fetch API не может загрузить. Ответ на запрос предварительной проверки не проходит проверку контроля доступа: в запрошенном ресурсе отсутствует заголовок "Access-Control-Allow-Origin". Поэтому источнику " http://127.0.0.1:3000/" запрещен доступ. Ответ имеет HTTP-код состояния 501. Если непрозрачный ответ удовлетворяет вашим потребностям, установите режим запроса "no-cors", чтобы получить ресурс с отключенным CORS.

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

Итак, есть ли проблема с реализацией? Я делаю это неправильно? Я не могу проверить журналы сервера, к сожалению. Я действительно немного застрял здесь.

function performSignIn() {

  let headers = new Headers();

  headers.append('Content-Type', 'application/json');
  headers.append('Accept', 'application/json');

  headers.append('Access-Control-Allow-Origin', 'http://localhost:3000');
  headers.append('Access-Control-Allow-Credentials', 'true');

  headers.append('GET', 'POST', 'OPTIONS');

  headers.append('Authorization', 'Basic ' + base64.encode(username + ":" + password));

  fetch(sign_in, {
      //mode: 'no-cors',
      credentials: 'include',
      method: 'POST',
      headers: headers
    })
    .then(response => response.json())
    .then(json => console.log(json))
    .catch(error => console.log('Authorization failed : ' + error.message));
}

Я использую Chrome. Я также пытался использовать этот плагин Chrome CORS, но затем я получаю другое сообщение об ошибке:

Значение заголовка "Access-Control-Allow-Origin" в ответе не должно быть подстановочным знаком "*", если режим учетных данных запроса "включить". Поэтому источнику " http://127.0.0.1:3000/" запрещен доступ. Режим учетных данных запросов, инициируемых XMLHttpRequest, контролируется атрибутом withCredentials.

37 ответов

Решение

Этот ответ охватывает много вопросов, поэтому он разделен на три части:

  • Как избежать предполетной проверки CORS
  • Как использовать прокси-сервер CORS для решения проблемы "Нет заголовка Access-Control-Allow-Origin"
  • Как исправить проблему "заголовок Access-Control-Allow-Origin не должен быть подстановочным знаком"

Как избежать предполетной проверки CORS

Код в вопросе запускает предварительную проверку CORS, так как отправляет Authorization заголовок.

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

Даже без этого Content-Type: application/json заголовок также запускает предпечатную проверку.

Что означает "предпечатная проверка": прежде чем браузер попытается POST в коде в вопросе, он сначала отправит OPTIONS запрос к серверу - определить, подключается ли сервер к получению перекрестного источника POST это включает в себя Authorization а также Content-Type: application/json заголовки.

Это работает довольно хорошо с небольшим скриптом curl - я получаю свои данные.

Чтобы правильно проверить с curl нужно эмулировать предпечатную проверку OPTIONS запрос браузер отправляет:

curl -i -X OPTIONS -H "Origin: http://127.0.0.1:3000" \
    -H 'Access-Control-Request-Method: POST' \
    -H 'Access-Control-Request-Headers: Content-Type, Authorization' \
    "https://the.sign_in.url"

…с https://the.sign_in.url заменено тем, что вы на самом деле sign_in URL есть.

Ответ, который браузер должен видеть из этого OPTIONS запрос должен включать заголовки, подобные этому:

Access-Control-Allow-Origin:  http://127.0.0.1:3000
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: Content-Type, Authorization

Если OPTIONS ответ не включает эти заголовки, тогда браузер остановится и даже не попытается отправить POST запрос. Кроме того, код состояния HTTP для ответа должен быть 2xx - обычно 200 или 204. Если это любой другой код состояния, браузер сразу же остановится.

Сервер в вопросе отвечает на OPTIONS запрос с кодом состояния 501, что, очевидно, означает, что он пытается указать, что не реализует поддержку OPTIONS Запросы. В этом случае другие серверы обычно отвечают кодом состояния 405 "Метод не разрешен".

Таким образом, вы никогда не сможете сделать POST запрашивает напрямую к этому серверу из вашего внешнего кода JavaScript, если сервер отвечает на это OPTIONS запросить с 405 или 501 или что-либо кроме 200 или 204 или если не отвечает с этими необходимыми заголовками ответа.

Способ избежать запуска предполета для рассматриваемого вопроса:

  • если сервер не требует Authorization заголовок запроса, но вместо этого (например) полагался на данные аутентификации, встроенные в тело POST запрос или как параметр запроса
  • если сервер не требует POST тело, чтобы иметь Content-Type: application/json тип носителя, но вместо этого принял POST тело как application/x-www-form-urlencoded с параметром по имени json (или что-то еще), чье значение является данными JSON

Как использовать прокси-сервер CORS для решения проблемы "Нет заголовка Access-Control-Allow-Origin"

Если вы не контролируете сервер, ваш код JavaScript отправляет запрос, и проблема с ответом с этого сервера заключается просто в отсутствии необходимого Access-Control-Allow-Origin заголовок, вы все еще можете заставить вещи работать - сделав запрос через прокси-сервер CORS. Чтобы показать, как это работает, сначала приведем код, который не использует прокси-сервер CORS:

const url = "https://example.com"; // site that doesn’t send Access-Control-*
fetch(url)
.then(response => response.text())
.then(contents => console.log(contents))
.catch(() => console.log("Can’t access " + url + " response. Blocked by browser?"))

Причина catch блок получает удар есть, браузер предотвращает доступ этого кода к ответу, который возвращается https://example.com, И причина, по которой браузер делает это, заключается в том, что ответу не хватает Access-Control-Allow-Origin заголовок ответа.

Теперь, вот точно такой же пример, но только с добавленным прокси-сервером CORS:

const proxyurl = "https://cors-anywhere.herokuapp.com/";
const url = "https://example.com"; // site that doesn’t send Access-Control-*
fetch(proxyurl + url) // https://cors-anywhere.herokuapp.com/https://example.com
.then(response => response.text())
.then(contents => console.log(contents))
.catch(() => console.log("Can’t access " + url + " response. Blocked by browser?"))

Примечание. Если https://cors-anywhere.herokuapp.com не работает или недоступен во время его попытки, ознакомьтесь с инструкциями по развертыванию собственного сервера CORS Anywhere на Heroku ниже, всего за 2-3 минуты.

Второй фрагмент кода, приведенный выше, может успешно получить доступ к ответу, потому что взятие URL-адреса запроса и его изменение на https://cors-anywhere.herokuapp.com/https://example.com - путем простого добавления префикса к URL-адресу прокси-сервера - вызывает сделать запрос через тот прокси, который затем:

  1. Направляет запрос на https://example.com,
  2. Получает ответ от https://example.com,
  3. Добавляет Access-Control-Allow-Origin заголовок к ответу.
  4. Передает этот ответ с добавленным заголовком обратно в запрашивающий код внешнего интерфейса.

Затем браузер позволяет коду внешнего интерфейса получить доступ к ответу, поскольку этот ответ с Access-Control-Allow-Origin Заголовок ответа - это то, что видит браузер.

Вы можете легко запустить свой собственный прокси, используя код с https://github.com/Rob--W/cors-anywhere/.
Вы также можете легко развернуть свой собственный прокси в Heroku буквально за 2-3 минуты, используя 5 команд:

git clone https://github.com/Rob--W/cors-anywhere.git
cd cors-anywhere/
npm install
heroku create
git push heroku master

После выполнения этих команд вы получите свой собственный сервер CORS Anywhere, например https://cryptic-headland-94862.herokuapp.com/. Так что вместо того, чтобы префикс вашего запроса URL с https://cors-anywhere.herokuapp.com вместо этого добавьте префикс URL для вашего собственного экземпляра; например, https://cryptic-headland-94862.herokuapp.com/https://example.com.

Поэтому, если вы попытаетесь использовать https://cors-anywhere.herokuapp.com, вы обнаружите, что он не работает (что иногда бывает), а затем подумайте о получении учетной записи Heroku (если вы этого еще не сделали) и возьмите 2 или 3 минуты, чтобы выполнить указанные выше действия для развертывания собственного сервера CORS Anywhere на Heroku.

Независимо от того, запускаете ли вы свой собственный или используете https://cors-anywhere.herokuapp.com/ или другой открытый прокси-сервер, это решение будет работать, даже если запрос вызывает браузеры на предварительную проверку CORS. OPTIONS запрос - потому что в этом случае прокси-сервер также отправляет обратно Access-Control-Allow-Headers а также Access-Control-Allow-Methods заголовки должны были сделать предпечатную проверку успешной.


Как исправить проблему "заголовок Access-Control-Allow-Origin не должен быть подстановочным знаком"

Я получаю еще одно сообщение об ошибке:

Значение заголовка "Access-Control-Allow-Origin" в ответе не должно быть подстановочным знаком "*", если режим учетных данных запроса "включить". Поэтому источнику " http://127.0.0.1:3000/ " запрещен доступ. Режим учетных данных запросов, инициируемых XMLHttpRequest, контролируется атрибутом withCredentials.

Для запроса, содержащего учетные данные, браузеры не позволят вашему веб-интерфейсу JavaScript получить доступ к ответу, если значение Access-Control-Allow-Origin заголовок ответа *, Вместо этого значение в этом случае должно точно соответствовать происхождению кода вашего внешнего интерфейса, http://127.0.0.1:3000,

См. Учетные запросы и подстановочные знаки в статье MDN HTTP контроль доступа (CORS).

Если вы управляете сервером, на который отправляете запрос, то обычным способом решения этого случая является настройка сервера на принятие значения Origin заголовок запроса и отразить / отразить это обратно в значение Access-Control-Allow-Origin заголовок ответа. Например, с помощью nginx:

add_header Access-Control-Allow-Origin $http_origin

Но это только один пример; другие (веб) серверные системы предоставляют аналогичные способы отображения исходных значений.


Я использую Chrome. Я также пытался использовать этот плагин Chrome CORS

Этот плагин Chrome CORS, очевидно, просто вводит Access-Control-Allow-Origin: * Заголовок в ответ, который видит браузер. Если бы плагин был умнее, он бы установил значение этого фейка Access-Control-Allow-Origin заголовок ответа для фактического происхождения вашего внешнего кода JavaScript, http://127.0.0.1:3000,

Поэтому избегайте использования этого плагина даже для тестирования. Это просто отвлечение. Если вы хотите проверить, какие ответы вы получаете с сервера, а браузер их не фильтрует, лучше использовать curl -H как указано выше.


Что касается внешнего кода JavaScript для fetch(…) запрос в вопросе:

headers.append('Access-Control-Allow-Origin', 'http://localhost:3000');
headers.append('Access-Control-Allow-Credentials', 'true');

Удалить эти строки. Access-Control-Allow-* Заголовки являются заголовками ответа. Вы никогда не хотите отправить их в запросе. Единственный эффект, который будет иметь место, - это запустить браузер для предварительной проверки.

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

Если у вас есть служба Spring REST, вы можете найти ее в блоге о поддержке CORS в Spring Framework.

Если вы размещаете сервис на сервере Node.js, то

  1. Остановите сервер Node.js.
  2. Npm установить Cors
  3. Добавьте следующие строки в ваш server.js

    var cors = require('cors')
    
    app.use(cors()) // Use this after the variable declaration
    

Проблема возникла потому, что вы добавили следующий код в качестве заголовка запроса в ваш интерфейс:

headers.append('Access-Control-Allow-Origin', 'http://localhost:3000');
headers.append('Access-Control-Allow-Credentials', 'true');

Эти заголовки принадлежат ответу, а не запросу. Поэтому удалите их, включая строку:

headers.append('GET', 'POST', 'OPTIONS');

Ваш запрос содержал "Content-Type: application/json", следовательно, вызвал то, что называется предварительным просмотром CORS. Это привело к тому, что браузер отправил запрос методом OPTIONS. См. Предварительную проверку CORS для получения подробной информации.
Поэтому в вашем бэкэнде вы должны обработать этот предварительно выданный запрос, возвращая заголовки ответа, которые включают:

Access-Control-Allow-Origin : http://localhost:3000
Access-Control-Allow-Credentials : true
Access-Control-Allow-Methods : GET, POST, OPTIONS
Access-Control-Allow-Headers : Origin, Content-Type, Accept

Конечно, фактический синтаксис зависит от языка программирования, который вы используете для своей серверной части.

В вашем интерфейсе это должно быть так:

function performSignIn() {
    let headers = new Headers();

    headers.append('Content-Type', 'application/json');
    headers.append('Accept', 'application/json');
    headers.append('Authorization', 'Basic ' + base64.encode(username + ":" +  password));
    headers.append('Origin','http://localhost:3000');

    fetch(sign_in, {
        mode: 'cors',
        credentials: 'include',
        method: 'POST',
        headers: headers
    })
    .then(response => response.json())
    .then(json => console.log(json))
    .catch(error => console.log('Authorization failed : ' + error.message));
}

В моем случае я использую решение ниже

Front-end или Angular

post(
    this.serverUrl, dataObjToPost,
    {
      headers: new HttpHeaders({
           'Content-Type':  'application/json',
         })
    }
)

back-end (использую php)

header("Access-Control-Allow-Origin: http://localhost:4200");
header('Access-Control-Allow-Methods: GET, POST, OPTIONS');
header("Access-Control-Allow-Headers: Content-Type, Authorization");

$postdata = file_get_contents("php://input");
$request = json_decode($postdata);
print_r($request);

Добавление mode:no-cors можно избежать проблемы cors в api.

fetch(sign_in, {
        mode: 'no-cors',
        credentials: 'include',
        method: 'POST',
        headers: headers
    })
    .then(response => response.json())
    .then(json => console.log(json))
    .catch(error => console.log('Authorization failed : ' + error.message));
}

Используйте dataType: 'jsonp', у меня работает.

   async function get_ajax_data(){
       var _reprojected_lat_lng = await $.ajax({
                                type: 'GET',
                                dataType: 'jsonp',
                                data: {},
                                url: _reprojection_url,
                                error: function (jqXHR, textStatus, errorThrown) {
                                    console.log(jqXHR)
                                },
                                success: function (data) {
                                    console.log(data);

                                    // note: data is already json type, you just specify dataType: jsonp
                                    return data;
                                }
                            });


 } // function               

Если ваш API написан на asp dot net core. Затем выполните следующие действия:

  • Установите пакет Microsoft.AspNetCore.Cors.

  • Добавьте строку ниже в метод ConfigureServices в Startup.cs:

            services.AddCors(); 
    
  • Добавьте строку ниже в методе Configure в startup.cs:

            app.UseCors(options =>
         options.WithOrigins("http://localhost:8080")
                .AllowAnyHeader()
                .AllowAnyMethod());
    
    make sure you add this before - app.UseRouting();
    

Только мои два цента... о том, как использовать прокси-сервер CORS, чтобы обойти проблемы "Нет заголовка Access-Control-Allow-Origin"

Для тех из вас, кто работает с php на сервере, развертывание "прокси-сервера CORS" так же просто, как:

  1. создайте файл с именем "no-cors.php" со следующим содержимым:

    $ URL = $ _GET ['url']; echo json_encode (file_get_contents ($ URL)); умереть();

  2. на вашем интерфейсе сделайте что-то вроде:

    fetch (' https://example.com/no-cors.php' + '? url =' + url).then (response => {/ Handle Response /})

Я знаю, что опаздываю, но это кому-то поможет

Возможная причина проблем с CORS

  • Проверьте заголовки доступа на стороне сервера: перейдите по этой ссылке
  • Проверьте, какой заголовок запроса получает от сервера в браузере, на изображении ниже показаны заголовки.
  • Если вы используете fetch метод и пытаясь получить доступ к запросу Cross-origin, убедитесь, что mode:corsздесь. Обратитесь к этой ссылке
  • Иногда, если в программе есть проблема, вы также получаете проблему с CORS, поэтому убедитесь, что ваш код работает правильно.
  • Обязательно обращайтесь с OPTION в вашем API.

Столкнулся с этой проблемой в моем приложении реакции/экспресс. Добавление приведенного ниже кода в(или имя файла вашего сервера) исправили проблему для меня. Установите корс, а затем

      const cors = require('cors');
app.use(cors({
    origin: 'http://example.com', // use your actual domain name (or localhost), using * is not recommended
    methods: ['GET', 'POST', 'PUT', 'DELETE', 'PATCH', 'HEAD', 'OPTIONS'],
    allowedHeaders: ['Content-Type', 'Origin', 'X-Requested-With', 'Accept', 'x-client-key', 'x-client-token', 'x-client-secret', 'Authorization'],
    credentials: true
}))

Теперь вы можете выполнять прямые вызовы API из внешнего интерфейса без необходимости передавать какие-либо дополнительные параметры.

В декабре 2021 года Chrome 97, Authorization: Bearer ...не допускается, если только он не находится в Access-Control-Allow-Headersпредварительный ответ (игнорирует ). Он выдал это предупреждение:

      [Deprecation] authorization will not be covered by the wildcard symbol (*)

См. Примечания к выпуску Chrome Enterprise, Chrome 97 .

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

В некоторых случаях библиотека может удалить Access-Control-Allow-Originзаголовок ответа, когда есть какие-то другие недопустимые учетные данные (пример: JWT с истекшим сроком действия ). Затем браузер показывает ошибку «Отсутствует заголовок Access-Control-Allow-Origin» вместо фактической ошибки (которая в этом примере может быть JWT с истекшим сроком действия). Убедитесь, что ваша библиотека не сбрасывает заголовок и не сбивает с толку клиента.

Для тех, кто использует ASP.NET Core:

В моем случае я использовал JavaScript для создания большого двоичного объекта из изображения, хранящегося в API (на сервере), поэтому URL-адрес указывал на этот ресурс. В этом APIprogram.csкласс, у меня уже была политика CORS , но она не работала.

После того, как я прочитал документацию Microsoft (прочитайте первый абзац) об этой проблеме, там сказано, что если вы хотите получить доступ к ресурсу на сервере с помощью JavaScript (что я и пытался сделать), то вы должны вызватьapp.UseCors(); перед _app.UseStaticFiles();что обычно бывает наоборот.

Мой файл program.cs :

      const string corsPolicyName = "ApiCORS";

builder.Services.AddCors(options =>
{
    options.AddPolicy(corsPolicyName, policy =>
    {
        policy.WithOrigins("https://localhost:7212");
    });
});

...

var app = builder.Build();

app.UseSwagger();

app.UseSwaggerUI(settings =>
{
    settings.DisplayRequestDuration();
    settings.EnableTryItOutByDefault();
});

app.UseHttpsRedirection();

app.UseCors(corsPolicyName); //  This should be above the UseStaticFiles();

app.UseStaticFiles(); //  Below the UseCors();

app.UseAuthentication();

app.UseAuthorization();

app.UseApiCustomExceptionHandler();

app.MapControllers();

app.Run();

В Nodejs, если вы используете маршрутизаторы, обязательно добавьте корс перед маршрутизаторами. В противном случае вы все равно получите ошибку cors. Как показано ниже:

const cors = require('cors');

const userRouter = require('./routers/user');

expressApp = express();
expressApp.use(cors());
expressApp.use(express.json());
expressApp.use(userRouter);

Я работал с Spring REST и решил, добавив AllowedMethods в WebMvcConfigurer.

@Value( "${app.allow.origins}" )
    private String allowOrigins;    
@Bean
public WebMvcConfigurer corsConfigurer() {
            System.out.println("allow origin: "+allowOrigins);
            return new WebMvcConfigurerAdapter() {
                @Override
                public void addCorsMappings(CorsRegistry registry) {
                    registry.addMapping("/**")
                    //.allowedOrigins("http://localhost")
                    .allowedOrigins(allowOrigins)
                    .allowedMethods("PUT", "DELETE","GET", "POST");
                }
            };
        }

In case you are using NodeJS/Express as back-end and ReactJS/axios as front-end within a development environment in MacOS, you need to run both sides under https. Below is what it finally worked for me (after many hours of deep dive & testing):

Step 1: Create an SSL certificate

Just follow the steps from How to get HTTPS working on your local development environment in 5 minutes

You will end up with a couple of files to be used as credentials to run the https server and ReactJS web:

server.key & server.crt

You need to copy them in the root folders of both the front and back ends (in a Production environment, you might consider copying them in./ssh for the back-end).

Step 2: Back-end setup

I read a lot of answers proposing the use of 'cors' package or even setting ('Access-Control-Allow-Origin', '*'), which is like saying: "Hackers are welcome to my website". Just do like this:

import express from 'express';
const emailRouter = require('./routes/email');  // in my case, I was sending an email through a form in ReactJS
const fs = require('fs');
const https = require('https');

const app = express();
const port = 8000;

// CORS (Cross-Origin Resource Sharing) headers to support Cross-site HTTP requests
app.all('*', (req, res, next) => {
    res.header("Access-Control-Allow-Origin", "https://localhost:3000");
    next();
});

// Routes definition
app.use('/email', emailRouter);

// HTTPS server
const credentials = {
  key: fs.readFileSync('server.key'),
  cert: fs.readFileSync('server.crt')
};

const httpsServer = https.createServer(credentials, app);
httpsServer.listen(port, () => {
    console.log(`Back-end running on port ${port}`);
});

In case you want to test if the https is OK, you can replace the httpsServer constant by the one below:

https.createServer(credentials, (req: any, res: any) => {
  res.writeHead(200);
  res.end("hello world from SSL\n");
}).listen(port, () => {
  console.log(`HTTPS server listening on port ${port}...`);
});

And then access it from a web browser: https://localhost:8000/

Step 3: Front-end setup

This is the axios request from the ReactJS front-end:

    await axios.get(`https://localhost:8000/email/send`, {
        params: {/* whatever data you want to send */ },
        headers: {
            'Content-Type': 'application/json',
        }
    })

And now, you need to launch your ReactJS web in https mode using the credentials for SSL we already created. Type this in your MacOS terminal:

HTTPS=true SSL_CRT_FILE=server.crt SSL_KEY_FILE=server.key npm start

At this point, you are sending a request from an https connection at port 3000 from your front-end, to be received by an https connection at port 8000 by your back-end. CORS should be happy with this;)

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

Таким образом, код будет примерно таким:

      app.use(cors());

....all other middleware here

app.use(function (req, res, next) {
  res.header("Access-Control-Allow-Origin", "http://localhost:3000");
  res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
  next();
});
...your routes

В моем случае решение было чертовски тупым... Ваше разрешенное происхождение не должно иметь косой черты в конце.

Например, https://example.com/-> https://example.com

Использование сборки WebAPI в .Net Core 6.0

Ничто из вышеперечисленного не сработало для меня... Это сделало это

      // global cors policy
   app.UseCors(x => x
        .AllowAnyMethod()
        .AllowAnyHeader()
        .SetIsOriginAllowed(origin => true) // allow any origin 
        .AllowCredentials());

кредит: /questions/59961222/politika-net-6-cors-zablokirovana-na-storone-klienta-cors/61458755#61458755

Удали это:

credentials: 'include',

В моем случае веб-сервер заблокировал метод "OPTIONS"

Проверьте свой веб-сервер на наличие метода опций

Я использую "webtier"

/www/webtier/domains/[domainname]/config/fmwconfig/components/OHS/VCWeb1/httpd.conf

<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteCond %{REQUEST_METHOD} ^OPTIONS
  RewriteRule .* . [F]
</IfModule>

изменить на

<IfModule mod_rewrite.c>
  RewriteEngine off
  RewriteCond %{REQUEST_METHOD} ^OPTIONS
  RewriteRule .* . [F]
</IfModule>

Я сталкивался с этой ошибкой несколько раз за последние несколько лет - она, казалось бы, неожиданно появлялась на ранее работающем веб-сайте. Я определил, что Chrome (и, возможно, другие браузеры) могут возвращать эту ошибку, когда на сервере возникает какая-то несвязанная ошибка, которая не позволяет ему обработать запрос CORS (и до возврата ошибки HTTP 500). Все это произошло в среде .Net Core, не уверен, что это произойдет в других средах. В любом случае, если ваш код функционировал раньше и кажется правильным, подумайте об отладке, чтобы определить, возникает ли какая-то другая ошибка, прежде чем вы сойдете с ума, пытаясь решить ошибку, которой на самом деле нет.

Простое решение для удаления No «Access-Control-Allow-Origin»

Установите заголовки django cors

pip установить django-cors-headers

Измените файл settings.py

добавьте это в INSTALLED_APPS -> «corsheaders»

Добавьте адрес клиента, которому разрешено использовать сервер. По сути, это адрес локального сервера реагирующего приложения. Это должна быть новая строка, а не внутри какого-либо списка или словаря. Вне всего.

CORS_ALLOWED_ORIGINS = ['http://localhost:3000']

Добавьте это в MIDDLEWARE

'corsheaders.middleware.CorsMiddleware'

После выполнения всей упомянутой выше работы эта ошибка исчезнет.

Нет «Контроль доступа-Разрешить-Происхождение»

Я использовал axios для отправки запроса на сервер Django. Команда для его установки

npm установить аксиос

Код для отправки запроса. Разместив код всего компонента, просто добавьте его в App.js.

      import axios from 'axios';
import React from 'react';

var data;

const getTheData = () => {
    axios.get('http://127.0.0.1:8000/')
        .then(res => {
            data = res.data;
            console.log(data);
        })
        .catch(err => { })
}

function GetData() {

    return (
        <div>
            <button onClick={getTheData()}>Get the data</button>
        </div>
    )
    
}

export default GetData;

Для node js express backend я использую это :)

Подробнее: https://enable-cors.org/server_expressjs.html.

Итак, я совершаю эту ошибку много раз, из-за этого я сделал «контрольный список» для всех вас.

  • Включите CORS в своем проекте: если вы используете NodeJS (например), вы можете использовать:

    npm установить корс; импортировать cors из 'cors';app.use(корс ());

  • Вы можете вручную установить заголовки следующим образом (если хотите):

    app.use((req, res, next) =>{res.setHeader('Access-Control-Allow-Origin', '*');res.setHeader('Access-Control-Allow-Headers','Origin, X-Requested-With, Content-Type,Accept, Authortization');
    res.setHeader('Acces-Control-Allow-Methods','GET, POST, PATCH, DELETE');

  • Не забудьте добавить http:// к вашей ссылке API в вашем внешнем проекте, некоторые браузеры, такие как Chrome, НЕ принимают запрос с использованием CORS, если URL-адрес запроса не http/https:

http://локальный:3000/апи

  • Проверьте, использует ли ваш проект proxy.config.js, см. здесь:

https://levelup.gitconnected.com/fixing-cors-errors-with-angular-cli-proxy-e5e0ef143f85

в случае, если вы вызываете API, разработанный на php, с помощью реакции js, вам нужно поместить следующий код в файл php

          header("Access-Control-Allow-Origin: http://localhost:4200");
    header('Access-Control-Allow-Methods: GET, POST, OPTIONS');
    header("Access-Control-Allow-Headers: Content-Type, Authorization");

На этот вопрос был дан ответ, но у меня есть конкретный случай, в который может попасть и какой-то другой разработчик.

У меня была та же проблема, и я продолжал ее отлаживать часами, и ни один из ответов на StackOverflow (или других форумах), похоже, не работал.

Проблема в том, что я использовал Kong в качестве шлюза API и не установил OPTIONS в качестве принятого метода.

конг.ямл:

      _format_version: "2.1"
_transform: true
services:
  - name: api
    url: http://backend:8393
    routes:
      - name: api
        methods:
          - PUT
          - POST
          - GET
          - DELETE
          - PATCH
          - OPTIONS // I didn't have this at first

        paths:
          - /api

Я надеюсь, что это поможет кому-то в будущем.

Я столкнулся с той же проблемой блокировки перекрестного происхождения при написании такого кода в расширении браузера. Напишите следующий код перед выполнением таких вызовов, вам не придется беспокоиться о заголовках, он все решит. После следующего кода вы можете выполнить столько вызовов между источниками, сколькокак вам нравится в этом сеансе.

      import Browser from 'webextension-polyfill'
Browser.permissions.request({ origins: ["https://*.example.com"] })

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

когда клиент использует для вызова нашей серверной службы со своего хоста username.companyname.com, он использует, чтобы получить указанную выше ошибку

Требуются две вещи:

  1. при отправке ответа отправьте заголовок, ключ которого - Access-Control-Allow-Origin, а значение - *

             context.Writer.Header()["Access-Control-Allow-Origin"] = []string{"*"} //important to avoid CORS error
    
  2. используйте библиотеку CORS golang, чтобы установить для AllowCredentials значение false, а для AllowAllOrigins - значение true.

Привет @daniel.lozynski . - одна из самых серьезных проблем, с которыми сталкиваются веб-разработчики при работе с API, и я долго работал над ее решениями.

Один из способов избавиться от них - использовать прокси. Конечно, у прокси бывают свои проблемы.

  1. Одна из их проблем в том, что это замедляет ваши запросы.
  2. Следующая проблема состоит в том, что некоторые из этих прокси-серверов делают небольшое количество запросов к вам в течение дня и иногда оставляют вас с too many requestsошибка. Конечно, эта проблема устраняется переключением между прокси.

Однако все это временные проблемы, которые возникают только во время разработки.

Ниже приведен список лучших прокси, которые я когда-либо находил.

  1. https://cors-anywhere.herokuapp.com/
  2. https://cors-proxy.htmldriven.com/?url=
  3. https://thingproxy.freeboard.io/fetch/
  4. https://thingproxy.freeboard.io
  5. http://thingproxy.freeboard.io
  6. http://www.whateverorigin.org/get?url=
  7. http://alloworigin.com/get?url=
  8. https://api.allorigins.win/get?url=
  9. https://yacdn.org/proxy/

Но как использовать эти прокси?

Вы можете легко оснастить API прокси и избавиться от Access-Control-Allow-Origin добавив любой из этих адресов перед своим IP-адресом.

Рассмотрим несколько примеров ниже:

Важный:

Использование прокси ограничено онлайн-API. И вы не можете использовать прокси в локальных API. Далее я скажу вам ответить и на локальные API ...

Так что я считаю лучшим решением?

Недавно я наткнулся на очень хорошее расширение Chrome, у которого до сих пор не было этих двух проблем с прокси-сервером, и я очень им доволен с тех пор, как использовал его.

Но единственная проблема с использованием этого плагина заключается в том, что вы больше не можете отлаживать свой проект на мобильном телефоне с IP-адресом. Это связано с тем, что этот плагин создает только прокси в вашем браузере и больше не влияет на передачу данных по кабелю по IP.

Вы можете найти и установить этот плагин по этой ссылке.

Разрешить CORS: Access-Control-Allow-Origin

Вы можете просто установить это расширение в свой браузер Chrome и получать удовольствие ...!

Использовать этот плагин очень и очень просто, вам просто нужно установить его, а затем активировать. Однако, если у вас возникла проблема с этим, на странице этого плагина в разделе «Расширения Chrome» есть видео YouTube, которое полностью решит ваши проблемы, просмотрев его.

Поскольку мой любимый браузер - это Chrome, я не искал решений для других расширений. Так что, если вы используете Chrome, этот плагин будет вам очень полезен.

Используйте приведенный ниже модуль npm. Это практически спасло жизни.

https://www.npmjs.com/package/local-cors-proxy

вы получаете ошибку CORS, например, как показано ниже URL

https://www.google.co.in/search/list

После успешной установки (local-cors-proxy) global npm install -g local-cors-proxyи установите URL-адрес прокси-сервера, который URL-адрес CORS. Например, здесь ниже проблема CORS, попадающая на localhost. Поэтому вам нужно добавить доменное имя и порт для домена проблемы CORS.

lcp --proxyUrl https://www.google.co.in --port 8010

После успешной установки он сгенерирует локальный URL-адрес прокси, как показано ниже.

http: // локальный:8010 / прокси

Используйте это доменное имя в URL-адресе API вашего проекта. Полный URL API

http: // локальный:8010 / прокси / поиск / список

Чтобы получить ответ на проблему без CORS в вашем локальном проекте.

Другие вопросы по тегам