Ответ на предварительный запрос не проходит проверку контроля доступа
Я получаю эту ошибку, используя ngResource для вызова REST API на Amazon Web Services:
XMLHttpRequest не удается загрузить http://server.apiurl.com:8000/s/login?login=facebook. Ответ на предварительный запрос не проходит проверку контроля доступа: нет Заголовок "Access-Control-Allow-Origin" присутствует на запрошенном ресурс. Происхождение'http://localhost', следовательно, не разрешен доступ. ошибка 405
сервис:
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'}
});
}]);
:
[...]
loginService.getUser(JSON.stringify(fbObj)),
function(data){
console.log(data);
},
function(result) {
console.error('Error', result.status);
}
[...]
Я использую Chrome, и я не знаю, что еще сделать, чтобы исправить эту проблему. Я даже настроил сервер для приема заголовков из origin localhost
.
17 ответов:
вы столкнулись с проблемами CORS.
есть несколько способов исправить это.
- выключите CORS. Например: как отключить cors в chrome
- используйте плагин для Вашего браузера
- используйте прокси, такие как nginx. пример того, как настроить
более подробно, вы пытаетесь получить доступ api.serverurl.com из localhost. Это точное определение кросс-домена запрос.
либо выключив его, чтобы выполнить свою работу (хорошо, поставьте плохую безопасность для вас, если вы посещаете другие сайты и просто пинаете банку вниз по дороге), вы можете использовать прокси-сервер, который заставляет ваш браузер думать, что все запросы поступают с локального хоста, когда на самом деле у вас есть локальный сервер, который затем вызывает удаленный сервер.
Итак api.serverurl.com может стать localhost: 8000 / api и ваш локальный nginx или другой прокси отправит правильный назначение.
теперь по многочисленным просьбам, 100% больше информации CORS....такой же отличный вкус!
и для downvoters.... обход CORS-это именно то, что показано для тех, кто просто изучает передний конец. https://codecraft.tv/courses/angular/http/http-with-promises/
мой "API-сервер" - это приложение PHP, поэтому для решения этой проблемы я нашел следующее решение для работы:
поместите строки в .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 " (ver 1.1.1) и добавление следующих изменений при запуске.цезий.
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
вы должны отправить Access-Control-Allow-Origin:* HTTP-заголовок со стороны сервера.
Если вы не используя Apache в качестве HTTP-сервера, вы можете добавить его в свой файл конфигурации Apache следующим образом:
<IfModule mod_headers.c> Header set Access-Control-Allow-Origin "*" </IfModule>
Mod_headers включен по умолчанию в Apache, однако вы можете убедиться, что он включен, запустив:
a2enmod headers
Если вы пишете chrome-extension
вы должны добавить
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';
С этим все разместить, сделать и т. д. будет работать нормально.
для тех, кто использует лямбда интегрированный прокси с API Gateway. Вам нужно настроить свою лямбда-функцию так, как если бы вы отправляли ей свои запросы напрямую, то есть функция должна правильно настроить заголовки ответов. (Если вы используете пользовательские лямбда-функции,это будет обрабатываться шлюзом API.)
//In your lambda's index.handler(): exports.handler = (event, context, callback) => { //on success: callback(null, { statusCode: 200, headers: { "Access-Control-Allow-Origin" : "*" } } }
в 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: *"); ...
в моем файле конфигурации 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 ^(.*)$ [R=200,L]
автономные дистрибутивы GeoServer включить сервер приложений пристани. Включить совместное использование ресурсов из разных источников (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>
Я думаю отключение CORS из Chrome не очень хороший способ, потому что если вы используете его в ионной, конечно, в мобильной сборке вопрос будет подниматься снова.
Так что лучше исправить в вашем интерфейсе.
прежде всего в заголовке, вам нужно установить-
- заголовок ('Access-Control-Allow-Origin: *');
- заголовок ('Header set Access-Control-Allow-Headers:" Origin, X-Requested-With, Content-Type, Accept");
и если API ведет себя как GET и POST, а затем также устанавливается в вашем заголовке-
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'])) заголовок ("Access-Control-Allow-Headers:
{$_SERVER ['HTTP_ACCESS_CONTROL_REQUEST_HEADERS']}"); exit (0);}
Я столкнулся с этой проблемой, когда DNS-сервер был установлен на 8.8.8.8 (Гугл). На самом деле, проблема была в маршрутизаторе, мое приложение пыталось подключиться к серверу через google, а не локально (для моего конкретного случая). Я удалил 8.8.8.8 и это решило проблему. Я знаю, что эти проблемы решаются настройками CORS, но, возможно, у кого-то будут такие же проблемы, как и у меня
то, что очень легко пропустить...
в обозревателе решений щелкните правой кнопкой мыши api-project. В окне свойств установите "анонимная аутентификация" на включено !!!
Я использую AWS sdk для загрузки, потратив некоторое время на поиск в Интернете, я наткнулся на эту тему. спасибо @lsimoneau 45581857 оказывается, происходит то же самое. Я просто указал свой Url-адрес запроса в регион на моем ведре, прикрепив свойство region, и это сработало.
const s3 = new AWS.S3({ accessKeyId: config.awsAccessKeyID, secretAccessKey: config.awsSecretAccessKey, region: 'eu-west-2' // add region here });