La réponse à la demande de contrôle en amont ne réussit pas la vérification du contrôle d'accès
Je reçois cette erreur en utilisant ngResource pour appeler une API REST sur Amazon Web Services:
XMLHttpRequest ne peut pas charger http://server.apiurl.com:8000/s/login?login=facebook . Réponse à La demande de preflight ne réussit pas le contrôle de contrôle d'accès: Non L'en-tête 'Access-Control-Allow-Origin' est présent sur le .__ demandé. Ressource. Origin ' http: // localhost ' n’est donc pas autorisé à accéder . Erreur 405
Un service:
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'}
});
}]);
Manette:
[...]
loginService.getUser(JSON.stringify(fbObj)),
function(data){
console.log(data);
},
function(result) {
console.error('Error', result.status);
}
[...]
J'utilise Chrome et je ne sais pas quoi faire pour résoudre ce problème. J'ai même configuré le serveur pour accepter les en-têtes de Origin localhost.
Mon "serveur API" est une application PHP. Pour résoudre ce problème, j'ai trouvé la solution ci-dessous qui fonctionnait
Placez les lignes dans 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');
Dans l’API Web AspNetCore, ce problème a été résolu en ajoutant "Microsoft.AspNetCore.Cors" (version 1.1.1) et en ajoutant les modifications ci-dessous dans Startup.cs.
public void ConfigureServices(IServiceCollection services)
{
services.AddCors(options =>
{
options.AddPolicy("AllowAllHeaders",
builder =>
{
builder.AllowAnyOrigin()
.AllowAnyHeader()
.AllowAnyMethod();
});
});
.
.
.
}
et
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
// Shows UseCors with named policy.
app.UseCors("AllowAllHeaders");
.
.
.
}
et mettre [EnableCors("AllowAllHeaders")] sur le contrôleur.
JavaScript XMLHttpRequest et Fetch respectent la politique de même origine. Alors, une application Web utilisant XMLHttpRequest ou Fetch ne peut générer que HTTP demandes à son propre domaine.
Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
Vous devez envoyer l'en-tête HTTP Access-Control-Allow-Origin: * à partir de votre serveur.
Si vous utilisez Apache comme serveur HTTP, vous pouvez l'ajouter à votre fichier de configuration Apache de la manière suivante:
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
Mod_headers est activé par défaut dans Apache. Toutefois, vous pouvez vous assurer qu'il est activé en exécutant:
a2enmod headers
Si vous écrivez un chrome-extension
Vous devez ajouter dans le manifest.json les autorisations pour votre (vos) domaine (s).
"permissions": [
"http://example.com/*",
"https://example.com/*"
]
Si vous utilisez le serveur IIS par hasard. vous pouvez définir les en-têtes ci-dessous dans l'option En-têtes de requête 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';
avec cela tout post, obtenir etc., fonctionnera bien.
Il y a des mises en garde concernant la SCRO. Premièrement, il n'autorise pas les caractères génériques * mais ne me retenez pas sur celui-ci. Je l'ai lu quelque part et je ne trouve pas l'article maintenant.
Si vous faites des demandes à partir d'un domaine différent, vous devez ajouter les en-têtes autoriser l'origine.
Access-Control-Allow-Origin: www.other.com
Si vous faites des demandes qui affectent des ressources du serveur telles que POST/PUT/PATCH et si le type mime est différent des application/x-www-form-urlencoded, multipart/form-data ou text/plain suivants, le navigateur émettra automatiquement une demande OPTIONS de pré-vol pour vérifier le permettrait.
Par conséquent, votre API/serveur doit gérer ces demandes OPTIONS en conséquence, vous devez répondre avec le access control headers approprié et le code de statut de réponse http doit être 200.
Les en-têtes devraient être quelque chose comme ceci, ajustez-les à vos besoins:
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, POST, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type
Access-Control-Max-Age: 86400
L'en-tête max-age est important, dans mon cas, cela ne fonctionnerait pas sans cela, je suppose que le navigateur a besoin de l'information pour savoir comment longtemps les "droits d'accès" sont valables.
En outre, si vous faites par exemple une demande POST avec application/json mime d'un autre domaine, vous devez également ajouter l'en-tête allow Origin précédemment mentionné, afin qu'il ressemble à ceci:
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
Lorsque le pré-vol réussit et que vous obtenez toutes les informations nécessaires, votre demande réelle sera formulée.
De manière générale, les en-têtes Access-Control demandés dans la demande initiale ou dans la demande préalable au vol doivent être indiqués dans la réponse pour que cela fonctionne.
Il existe un bon exemple dans la documentation MDN ici sur ce lien , et vous devriez également consulter ce SO post
Dans PHP, vous pouvez ajouter les en-têtes:
<?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: *");
...
Pour le serveur de flacon python, vous pouvez utiliser le plugin flask-cors pour activer les requêtes interdomaine.
Pour résoudre les problèmes liés aux requêtes inter-origines dans une application Node JS:
npm i cors
Et ajoutez simplement les lignes ci-dessous au app.js
let cors = require('cors')
app.use(cors())
Dans mon fichier de configuration Apache VirtualHost, j'ai ajouté les lignes suivantes:
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]
Pour ceux qui utilisentLambda Integrated Proxy avec API Gateway. Vous devez configurer votre fonction lambda comme si vous lui soumettiez directement vos demandes, ce qui signifie que la fonction devrait configurer correctement les en-têtes de réponse. (Si vous utilisez des fonctions lambda personnalisées, cela sera géré par la passerelle API.)
//In your lambda's index.handler():
exports.handler = (event, context, callback) => {
//on success:
callback(null, {
statusCode: 200,
headers: {
"Access-Control-Allow-Origin" : "*"
}
}
}
J'ai été confronté à ce problème lorsque le serveur DNS était défini sur 8.8.8.8 (Google). En fait, le problème venait du routeur, mon application a essayé de se connecter au serveur via Google, pas localement (dans mon cas particulier). J'ai supprimé 8.8.8.8 et cela a résolu le problème ... Je sais que ce problème a été résolu par les paramètres de la SCRO, mais peut-être que quelqu'un aura le même problème que moi
J'utilise AWS sdk pour les téléchargements, après avoir passé du temps à chercher en ligne, je suis tombé sur ce fil. grâce à @lsimoneau 45581857 il s’est avéré qu’il se passait exactement la même chose. J'ai simplement indiqué mon URL de requête à la région de mon panier en joignant l'option de région et cela a fonctionné.
const s3 = new AWS.S3({
accessKeyId: config.awsAccessKeyID,
secretAccessKey: config.awsSecretAccessKey,
region: 'eu-west-2' // add region here });
Les distributions autonomes de GeoServer incluent le serveur d’application Jetty. Activez le partage de ressources d'origine croisée (CORS) Pour permettre aux applications JavaScript situées en dehors de votre propre domaine d'utiliser GeoServer.
Décommentez les <filter> et <filter-mapping> suivants 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>
Une cause très courante de cette erreur pourrait être que l’API de l’hôte mappait la demande à une méthode http (par exemple, PUT) et que le client de l’API appelle l’API à l’aide d’une méthode http différente (par exemple, POST ou GET).
Notre équipe le voit parfois à l’aide de Vue, axios et d’une API Web C #. Ajouter un attribut de route sur le noeud final que vous essayez de résoudre nous le corrige.
[Route("ControllerName/Endpoint")]
[HttpOptions, HttpPost]
public IHttpActionResult Endpoint() { }
Je pense que désactiver CORS depuis Chrome n’est pas une bonne solution , car si vous l’utilisez en mode ionique, il est certain que dans Mobile Build, le problème se posera à nouveau.
Il est donc préférable de corriger dans votre backend.
Tout d’abord, dans l’en-tête, vous devez définir
- en-tête ('Access-Control-Allow-Origin: *');
- header ('Ensemble d'en-têtes Access-Control-Allow-Headers: "Origine, X-Demandé avec, Type de contenu, Accepter"');
Et si l’API se comporte comme GET et POST, alors aussi Set in
if ($ _SERVER ['REQUEST_METHOD'] == 'OPTIONS') {if (isset ($ _ SERVER ['HTTP_ACCESS_CONTROL_REQUEST_METHOD']))) en-tête ("méthodes d'accès-contrôle-autoriser: GET, POST, OPTIONS");
if (isset ($ _ SERVER ['HTTP_ACCESS_CONTROL_REQUEST_HEADERS']))) header ("Access-Control-Allow-Headers:
{$ _SERVER ['HTTP_ACCESS_CONTROL_REQUEST_HEADERS']} "); exit (0);}