Pourquoi mon code JavaScript ne génère-t-il pas un en-tête "Aucun 'En-tête" n'est présent sur la ressource demandée "alors que Postman n'en contient pas?
J'essaie de faire une autorisation en utilisant JavaScript en me connectant au RESTfulAPI intégré Flask . Cependant, lorsque je fais la demande, j'obtiens l'erreur suivante:
XMLHttpRequest ne peut pas charger http: // myApiUrl/login . Aucun en-tête 'Access-Control-Allow-Origin' n'est présent sur la ressource demandée. Origin 'null' n'est donc pas autorisé à accéder.
Je sais que l'API ou la ressource distante doit définir l'en-tête, mais pourquoi cela a-t-il fonctionné lorsque j'ai fait la demande via l'extension Chrome Postman ?
C'est le code de demande:
$.ajax({
type: "POST",
dataType: 'text',
url: api,
username: 'user',
password: 'pass',
crossDomain : true,
xhrFields: {
withCredentials: true
}
})
.done(function( data ) {
console.log("done");
})
.fail( function(xhr, textStatus, errorThrown) {
alert(xhr.responseText);
alert(textStatus);
});
Si j'ai bien compris, vous faites un XMLHttpRequest vers un domaine différent de celui de votre page. Donc, le navigateur le bloque car il permet généralement une demande dans la même origine pour des raisons de sécurité. Vous devez faire quelque chose de différent lorsque vous souhaitez effectuer une requête entre domaines. Un tutoriel sur comment y parvenir est Using CORS.
Lorsque vous utilisez postman, ils ne sont pas limités par cette stratégie. Cité de Origine croisée XMLHttpRequest:
Les pages Web standard peuvent utiliser l'objet XMLHttpRequest pour envoyer et recevoir des données de serveurs distants, mais elles sont limitées par la même stratégie d'origine. Les extensions ne sont pas si limitées. Une extension peut communiquer avec des serveurs distants en dehors de son origine, à condition qu'elle demande d'abord des autorisations croisées.
Ce n'est pas un correctif pour la production ou lorsque l'application doit être présentée au client, cela n'est utile que lorsque l'interface utilisateur et Backend development se trouvent sur différents servers et qu'ils sont en production sur le même serveur. Par exemple: lors du développement de l'interface utilisateur pour toute application s'il est nécessaire de la tester localement en la dirigeant vers le serveur principal, dans ce scénario, le correctif idéal. Pour le correctif de production, les en-têtes CORS doivent être ajoutés au serveur principal pour permettre l'accès croisé à l'origine.
Le moyen le plus simple est d’ajouter l’extension dans Google Chrome pour permettre l’accès via CORS.
Activez simplement cette extension chaque fois que vous souhaitez autoriser l'accès à aucune demande d'en-tête 'access-control-allow-Origin'.
Ou
Sous Windows, collez cette commande dans la fenêtre run
chrome.exe --user-data-dir="C:/Chrome dev session" --disable-web-security
cela ouvrira un nouveau navigateur chrome qui n'autorisera l'accès à aucune demande d'en-tête 'access-control-allow-Origin'.
Si vous pouvez utiliser JSON en retour, essayez d'utiliser JSONP (notez le P à la fin) pour parler entre les domaines:
$.ajax({
type: "POST",
dataType: 'jsonp',
...... etc ......
En savoir plus sur le travail avec JSONP ici :
L'avènement de JSONP - essentiellement un piratage consensuel de scripts intersites - a ouvert la porte à de puissants mashups de contenu. De nombreux sites importants fournissent des services JSONP, vous permettant d'accéder à leur contenu via une API prédéfinie.
C'est très simple à résoudre si vous utilisez PHP . Ajoutez simplement le script suivant au début de votre page PHP qui gère la requête:
<?php header('Access-Control-Allow-Origin: *'); ?>
Attention: Ceci contient un problème de sécurité pour votre fichier PHP qui pourrait être appelé par des attaquants. vous devez utiliser des sessions et des cookies pour l'authentification afin d'empêcher votre fichier/service de vous attaquer. Votre service est vulnérable à la falsification de requêtes inter-sites (CSRF).
Si vous utilisez Node-red , vous devez autoriser CORS dans le fichier node-red/settings.js en commentant les lignes suivantes:
// The following property can be used to configure cross-Origin resource sharing
// in the HTTP nodes.
// See https://github.com/troygoode/node-cors#configuration-options for
// details on its contents. The following is a basic permissive set of options:
httpNodeCors: {
Origin: "*",
methods: "GET,PUT,POST,DELETE"
},
Je souhaite que quelqu'un partage ce site avec moi il y a longtemps http://cors.io/ il aurait économisé une tonne de temps par rapport à la construction et à la confiance en mon propre proxy Cependant, lorsque vous passez à la production, disposer de votre propre proxy est la meilleure solution, car vous contrôlez toujours tous les aspects de vos données.
Tout ce dont tu as besoin:
https://cors.io/?http://HTTP_YOUR_LINK_HERE
Si vous utilisez Node.js , essayez-le:
app.use(function(req, res, next) {
res.header("Access-Control-Allow-Origin", "*");
res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
next();
});
Plus d'informations: CORS sur ExpressJS
Il existe un problème inter-domaines utilisant Ajax. Vous devez être sûr que vous accédez à vos fichiers sur le même chemin http:// sans www. (ou un accès à partir de http://www. et une publication sur le même chemin, y compris www.) que le navigateur considère comme un autre domaine lors d'un accès via un chemin www.. est. Vous publiez dans un autre domaine et le navigateur bloque le flux en raison du problème Origine.
Si le API n'est pas placé sur le même hôte que celui que vous demandez, le flux est bloqué et vous devrez trouver un autre moyen de communiquer avec l'API.
Parce que
$ .ajax ({type: "POST" - Appelle OPTIONS
$ .post ( - Appelle POST
les deux sont des appels différents de Postman "POST" correctement mais quand nous appelons ce sera "OPTIONS"
Pour les services Web c # - webapi
Veuillez ajouter le code suivant dans votre fichier web.config sous la balise <system.webServer>. Ça va marcher
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
</customHeaders>
</httpProtocol>
Veuillez vous assurer que vous ne faites pas d'erreur dans l'appel ajax
jQuery
$.ajax({
url: 'http://mysite.Microsoft.sample.xyz.com/api/mycall',
headers: {
'Content-Type': 'application/x-www-form-urlencoded'
},
type: "POST", /* or type:"GET" or type:"PUT" */
dataType: "json",
data: {
},
success: function (result) {
console.log(result);
},
error: function () {
console.log("error");
}
});
Numéro 4 angulaire s'il vous plaît se référer: http://www.hubfly.com/blog/solutions/how-to-fix-angular-4-api-call-issues/
Remarque: Si vous souhaitez télécharger du contenu à partir d'un site Web tiers, alors cela ne vous aidera pas. Vous pouvez essayer le code suivant mais pas JavaScript.
System.Net.WebClient wc = new System.Net.WebClient();
string str = wc.DownloadString("http://mysite.Microsoft.sample.xyz.com/api/mycall");
Essayez XDomain ,
Résumé: Une alternative/polyfill pure en JavaScript CORS. Aucune configuration de serveur requise - ajoutez simplement un fichier proxy.html sur le domaine avec lequel vous souhaitez communiquer. Cette bibliothèque utilise XHook pour raccorder tous les XHR , de sorte que XDomain devrait fonctionner conjointement avec n’importe quelle bibliothèque.
Si tu ne veux pas:
- Désactiver la sécurité Web dans Chrome
- Utilisez JSONP
- Utilisez un site tiers pour rediriger vos demandes
et vous êtes sûr que CORS est activé sur votre serveur (testez CORS ici: http://www.test-cors.org/ )
Ensuite, vous devez passer le paramètre Origin avec votre demande . Cette origine DOIT correspondre à l’origine que votre navigateur envoie à votre demande.
Vous pouvez le voir en action ici: http://www.wikinomad.com/app/detail/Campgrounds/3591
La fonctionnalité d'édition envoie une demande GET & POST à un autre domaine pour récupérer les données. Je règle le paramètre Origin qui résout le problème . Le backend est un moteur mediaWiki.
tldr: Ajoutez à vos appels le paramètre "Origine" qui doit être le paramètre Origine envoyé par votre navigateur (vous ne pouvez pas usurper le paramètre Origine).
J'ai eu un problème avec cela lorsque j'ai utilisé AngularJS pour accéder à mon API. La même demande a fonctionné dans SoapUI 5.0 et ColdFusion. Ma méthode GET avait déjà un en-tête Access-Control-Allow-Origin.
J'ai découvert que AngularJS fait une requête "d'essai" OPTIONS . ColdFusion, par défaut, génère la méthode OPTIONS, mais elle n’a pas beaucoup, ces en-têtes spécifiquement. L'erreur a été générée en réponse à cet appel OPTIONS et non à mon appel intentionnel à GET. Après avoir ajouté la méthode OPTIONS ci-dessous à mon API, le problème a été résolu.
<cffunction name="optionsMethod" access="remote" output="false" returntype="any" httpmethod="OPTIONS" description="Method to respond to AngularJS trial call">
<cfheader name="Access-Control-Allow-Headers" value="Content-Type,x-requested-with,Authorization,Access-Control-Allow-Origin">
<cfheader name="Access-Control-Allow-Methods" value="GET,OPTIONS">
<cfheader name="Access-Control-Allow-Origin" value="*">
<cfheader name="Access-Control-Max-Age" value="360">
</cffunction>
J'ai eu la configuration suivante, entraînant la même erreur, lorsque j'ai demandé des réponses au serveur.
Server-side:SparkJava -> fournit l'API REST
Côté client:ExtJs6 -> fournit le rendu du navigateur.
Sur le côté serveur, je devais ajouter ceci à la réponse:
Spark.get("/someRestCallToSpark", (req, res) -> {
res.header("Access-Control-Allow-Origin", "*"); //important, otherwise its not working
return "some text";
});
Sur le côté client, je devais ajouter ceci à la requête:
Ext.Ajax.request({
url: "http://localhost:4567/someRestCallToSpark",
useDefaultXhrHeader: false, //important, otherwise its not working
success: function(response, opts) {console.log("success")},
failure: function(response, opts) {console.log("failure")}
});
Sur la base de la réponse de shruti , j'ai créé un raccourci du navigateur Chrome avec les arguments nécessaires: 
https://github.com/Rob--W/cors-anywhere/ fournit le code (Node.js) que vous pouvez utiliser pour configurer et exécuter votre propre proxy CORS. Il est activement mis à jour et fournit un certain nombre de fonctionnalités pour contrôler le comportement du proxy, au-delà de l’envoi de base des en-têtes de réponse Access-Control-* corrects.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS a des détails pour expliquer comment les navigateurs traitent les demandes cross-Origin que les applications Web côté client font à partir de JavaScript et quels en-têtes vous devez configurez l'envoi par le serveur auquel la demande est faite, si vous le pouvez.
Dans le cas où un site pour lequel vous devez demander et obtenir une réponse ne renvoie pas l'en-tête de réponse Access-Control-Allow-Origin, les navigateurs sont always vont bloquer les demandes cross-Origin qui leur sont adressées directement par votre côté client. Code JavaScript de travail. Et donc, si le site n’est pas celui que vous contrôlez et pour lequel vous pouvez configurer le comportement, la seule chose qui fonctionnera dans ce cas-ci consiste à transmettre les demandes par proxy, soit par votre propre proxy que vous exécutez vous-même, soit par un proxy ouvert.
Comme mentionné dans d'autres commentaires ici, il y a de bonnes raisons de ne pas faire confiance à un proxy ouvert avec vos demandes. Cela dit, si vous savez ce que vous faites et décidez qu'un proxy ouvert convient à vos besoins, https://cors-anywhere.herokuapp.com/ est un serveur fiable, disponible et maintenu activement, et qui fonctionne. une instance du https://github.com/Rob--W/cors-anywhere/ code.
Comme pour les autres proxies ouverts mentionnés ici (quelques-uns au moins ne semblent plus être disponibles), le système fonctionne comme suit: au lieu que votre code client envoie une demande directement à, par exemple, http://foo.com, vous l'envoyez à https://cors-anywhere.herokuapp.com/http://foo.com et le proxy ajoute les en-têtes Access-Control-* nécessaires à la réponse affichée par le navigateur.
Vous pouvez contourner le problème en utilisant YQL pour proxyer la demande via les serveurs de Yahoo. Ce ne sont que quelques lignes de code:
var yql_url = 'https://query.yahooapis.com/v1/public/yql';
var url = 'your api url';
$.ajax({
'url': yql_url,
'data': {
'q': 'SELECT * FROM json WHERE url="'+url+'"',
'format': 'json',
'jsonCompat': 'new',
},
'dataType': 'jsonp',
'success': function(response) {
console.log(response);
},
});
Voici le lien avec une explication: https://vverma.net/fetch-any-json-using-jsonp-and-yql.html
Si vous utilisez Entity Framework , il semble que cette erreur soit parfois générée même si vous avez activé CORS. J'ai compris que l'erreur était due à une finalisation manquante de la requête. J'espère que cela aidera d'autres personnes dans la même situation.
Le code suivant peut générer l'erreur XMLHttpRequest cannot load http://myApiUrl/login. No 'Access-Control-Allow-Origin' header is present on the requested resource.:
using (DBContext db = new DBContext())
{
return db.Customers.Select(x => new
{
Name = x.Name,
CustomerId = x.CustomerId,
});
}
Pour résoudre ce problème, un appel de finalisation comme .ToList() ou .FirstOrDefault() à la fin de la requête est requis, comme suit:
using (DBContext db = new DBContext())
{
return db.Customers.Select(x => new
{
Name = x.Name,
CustomerId = x.CustomerId,
}).ToList();
}
Dans mon cas, j'utilisais l'application JEE7 JAX-RS et les astuces suivantes me convenaient parfaitement:
@GET
@Path("{id}")
public Response getEventData(@PathParam("id") String id) throws FileNotFoundException {
InputStream inputStream = getClass().getClassLoader().getResourceAsStream("/eventdata/" + id + ".json");
JsonReader jsonReader = Json.createReader(inputStream);
return Response.ok(jsonReader.readObject()).header("Access-Control-Allow-Origin", "*").build();
}
Si vous recevez ce message d'erreur du navigateur:
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin '…' is therefore not allowed access
lorsque vous essayez de faire une demande Ajax POST/GET à un serveur distant hors de votre contrôle, oubliez ce simple correctif:
<?php header('Access-Control-Allow-Origin: *'); ?>
Vous avez vraiment besoin, surtout si vous utilisez uniquement du JavaScript pour effectuer la requête Ajax, d'un proxy interne qui prend votre requête et l'envoie au serveur distant.
Tout d’abord dans votre code JavaScript, effectuez un appel Ajax sur votre propre serveur, quelque chose comme:
$.ajax({
url: yourserver.com/controller/proxy.php,
async: false,
type: "POST",
dataType: "json",
data: data,
success: function (result) {
JSON.parse(result);
},
error: function (xhr, ajaxOptions, thrownError) {
console.log(xhr);
}
});
Créez ensuite un simple fichier PHP appelé proxy.php pour envelopper vos données POST et les ajouter au paramètre comme serveur d'URL distant. Je vous donne un exemple de contournement de ce problème avec l’API de recherche d’hôtels Expedia:
if (isset($_POST)) {
$apiKey = $_POST['apiKey'];
$cid = $_POST['cid'];
$minorRev = 99;
$url = 'http://api.ean.com/ean-services/rs/hotel/v3/list?' . 'cid='. $cid . '&' . 'minorRev=' . $minorRev . '&' . 'apiKey=' . $apiKey;
echo json_encode(file_get_contents($url));
}
En faisant:
echo json_encode(file_get_contents($url));
Vous faites juste la même requête, mais côté serveur et après cela, cela devrait fonctionner correctement.
Réponse copiée et collée depuis NizarBsb
J'ai réussi à résoudre (dans mon cas pour les polices) en utilisant htaccess mais évidemment, OP demande peu différent. Mais vous pouvez utiliser le modèle FileMatch et ajouter n'importe quel type d'extension pour éviter les erreurs cros.
<IfModule mod_headers.c>
<FilesMatch "\.(ttf|ttc|otf|eot|woff|woff2|font.css|css)$">
Header set Access-Control-Allow-Origin "*"
</FilesMatch>
</IfModule>
Pour l'API GoLang:
Commencez par regarder MDN CORS Doc pour savoir ce que CORS est. Autant que je sache, CORS consiste à autoriser ou non Origin Of Request à accéder à Server Resource.
De plus, vous pouvez limiter la demande à laquelle Origin peut accéder au serveur en définissant Access-Control-Allow-Origin dans Header of Server Response.
Par exemple, si vous définissez l'en-tête suivant dans Server Response, seule la requête envoyée à partir de http://foo.example peut accéder à votre serveur:
Access-Control-Allow-Origin: http://foo.example
et après la demande d’autorisation envoyée à partir de n’importe quel pays (ou domaine):
Access-Control-Allow-Origin: *
Et comme je le sais dans le message d'erreur, requested resource signifie ressource du serveur, donc No 'Access-Control-Allow-Origin' header is present on the requested resource. signifie que vous n'avez pas défini l'en-tête Access-Control-Allow-Origin dans votre réponse au serveur, ou peut-être que vous avez défini mais que l'origine de la demande ne figure pas dans Access-Control-Allow-Origin; accès:
Aucun en-tête 'Access-Control-Allow-Origin' n'est présent sur la ressource demandée. Origin 'null' n'est donc pas autorisé à accéder.
Dans GoLang, j'utilise le package gorilla/mux pour construire le serveur d'API à localhost:9091, et j'autorise CORS en ajoutant "Access-Control-Allow-Origin", "*" à l'en-tête de la réponse:
func main() { // API Server Code
router := mux.NewRouter()
// API route is /people,
//Methods("GET", "OPTIONS") means it support GET, OPTIONS
router.HandleFunc("/people", GetPeople).Methods("GET", "OPTIONS")
log.Fatal(http.ListenAndServe(":9091", router))
}
// Method of '/people' route
func GetPeople(w http.ResponseWriter, r *http.Request) {
// Allow CORS by setting * in sever response
w.Header().Set("Access-Control-Allow-Origin", "*")
w.Header().Set("Access-Control-Allow-Headers", "Content-Type")
json.NewEncoder(w).Encode("OKOK")
}
Et j'utilise JavaScript dans le client. À localhost:9092, la requête de Chrome peut obtenir avec succès "OKOK" du serveur localhost:9091.
function GetPeople() {
try {
var xhttp = new XMLHttpRequest();
xhttp.open("GET", "http://localhost:9091/people", false);
xhttp.setRequestHeader("Content-type", "text/html");
xhttp.send();
var response = JSON.parse(xhttp.response);
alert(xhttp.response);
}
catch (error) {
alert(error.message);
}
}
En outre, vous pouvez vérifier votre en-tête de demande/réponse à l'aide d'outils tels que Fiddler.
Question populaire - Une autre chose à regarder si vous avez lu jusqu'à présent et que rien d'autre n'a aidé. Si vous disposez d'un CDN tel qu'Akamai, Limelight ou similaire, vous pouvez vérifier la clé de cache que vous avez pour l'URI de la ressource. S'il n'inclut pas la valeur de l'en-tête Origin, il est possible que vous retourniez une réponse en cache à la demande d'une autre origine. Nous venons de passer une demi-journée à déboguer cela. La configuration de CDN a été mise à jour pour inclure uniquement la valeur d'origine pour quelques domaines sélectionnés qui sont les nôtres et la définir sur null pour tous les autres. Cela semble fonctionner et permet aux navigateurs de nos domaines connus d'afficher nos ressources. Certes, toutes les autres réponses sont des conditions préalables pour arriver ici, mais si le CDN est le premier saut effectué par votre navigateur, vous devez l'examiner.
Dans notre cas, nous avons pu constater que certaines demandes parviennent à notre service, mais pas autant que le volume envoyé par le site. Cela nous a indiqué le CDN. Nous avons pu revenir en arrière et voir que la demande d'origine avait été servie à partir d'une demande directe, ne faisant pas partie d'un appel du navigateur AJAX et l'en-tête de la réponse Access-Control-Allow-Origin n'était pas inclus. Apparemment, le CDN a mis cette valeur en cache. La configuration CDN d’Akamai visant à prendre en compte la valeur de l’en-tête de la demande d’origine dans le cadre de la correspondance semble avoir permis à la solution de fonctionner.
mettez ceci devant votre url: https://cors-anywhere.herokuapp.com/
ainsi, par exemple: https://cors-anywhere.herokuapp.com/https://www.ndbc.noaa.gov/data/realtime2/46258.txt
Souvent, cela m'arrive de javascript à mon api php, pour l'une des raisons suivantes. J'ai oublié de mettre la <?php header('Access-Control-Allow-Origin: *'); ? en est une. Ceci est utile pour l’accès à plusieurs sous-domaines. Une autre raison est que, dans la demande ajax jQuery, je spécifie un type de données spécifique et renvoie un type de données différent, ainsi une erreur est renvoyée.
Le dernier et le plus important des motifs de cette erreur est qu’il existe une erreur d’analyse sur la page que vous demandez. Si vous cliquez sur cette page dans votre navigateur, vous verrez probablement une erreur d’analyse et vous aurez un numéro de ligne pour résoudre le problème.
J'espère que ça aidera quelqu'un. Il m'a fallu un certain temps à chaque fois pour résoudre ce problème et j'aimerais avoir une liste de vérification des éléments à vérifier.
Dans la demande jsonp, vous devez capturer "jsonpCallback" et le renvoyer.
$.ajax({
url: lnk,
type: 'GET',
crossDomain: true,
dataType: 'jsonp',
success: function (ip) { console.log(ip.ip); },
error: function (err) { console.log(err) }
});
Du côté backend (si vous utilisez PHP en tant que backend)
echo $_GET['callback'].'({"ip":"192.168.1.1"})';
Dans ce cas, la réponse principale semble être
jQuery331009526199802841284_1533646326884 ({"ip": "192.168.1.1"})
mais vous pouvez définir un "jsonpCallback" manuellement sur le frontend et l'attraper sur le côté backend
$.ajax({
url: lnk,
type: 'GET',
crossDomain: true,
dataType: 'jsonp',
jsonpCallback: 'get_ip',
success: function (ip) { console.log(ip.ip); },
error: function (err) { console.log(err) }
});
Dans ce cas, la réponse principale semble être
get_ip ({"ip": "192.168.1.1"})
Sur mon site Web (basé sur .NET), je viens d'ajouter ceci:
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
<add name="Access-Control-Allow-Headers" value="Content-Type" />
<add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS" />
</customHeaders>
</httpProtocol>
</system.webServer>
Un grand merci à this video.
au cas où vous voudriez résoudre ce problème sur le backend (dans Flask), plutôt que sur le front-end, je recommanderais totalement le paquet pask Flask CORS Flacon Cors
Avec une simple ligne dans votre application.py, vous pouvez insérer automatiquement l’en-tête standard autoriser tout en-tête d’origine ou le personnaliser à votre guise.
Pour être complet, Apache autorise cors:
Header set Access-Control-Allow-Origin "http://www.allowonlyfromthisurl.com"
Header set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
Header set Access-Control-Max-Age "1000"
Header set Access-Control-Allow-Headers "x-requested-with, Content-Type, Accept-Encoding, Accept-Language, Cookie, Referer"
CORS est pour vous.
CORS est un "partage de ressources d'origine croisée" et constitue un moyen d'envoyer une demande interdomaine. Maintenant, les API XMLHttpRequest2 et Fetch prennent en charge CORS.
Mais il a ses limites. Le serveur doit déclarer spécifiquement le Access-Control-Allow-Origin, et il ne peut pas être défini sur '*'.
Et si vous souhaitez que n'importe quelle origine puisse vous envoyer une demande, vous avez besoin de JSONP (vous devez également définir Access-Control-Allow-Origin, mais vous pouvez indiquer '*').
Pour de nombreuses demandes, si vous ne savez pas quoi choisir, je pense que vous avez besoin d’un composant entièrement fonctionnel pour le faire. Permettez-moi de vous présenter un composant simple catta
Si vous utilisez un navigateur moderne (> Internet Explorer9, Chrome, Firefox, Edge, etc.), il est fortement recommandé d’utiliser un composant simple mais beau, https://github.com/Joker-Jelly/catta. Il n'a pas de dépendances, est inférieur à 3 Ko et prend en charge Fetch, Ajax et JSONP avec la même syntaxe et les mêmes options.
catta('./data/simple.json').then(function (res) {
console.log(res);
});
Il prend également en charge tout le chemin d'importation dans votre projet, comme le module ES6, CommonJS et même <script> en HTML.
La plupart de ces réponses indiquent aux utilisateurs comment ajouter des en-têtes CORS à un serveur qu’ils contrôlent.
Toutefois, si vous avez besoin de données provenant d'un serveur que vous ne contrôlez pas dans une page Web, une solution consiste à créer une balise de script sur votre page, définissez l'attribut src sur le point de terminaison api sans en-têtes CORS, puis chargez ces données sur la page:
window.handleData = function(data) {
console.log(data)
};
var script = document.createElement('script');
script.setAttribute('src','https://some.api/without/cors/headers.com&callback=handleData');
document.body.appendChild(script);
J'ai eu cette erreur avec $http.get dans Angular. Je devais utiliser$http.jsonpà la place.
C’est peut-être un peu compliqué, mais vous pouvez utiliser un serveur Web pour acheminer la demande . Je ne suis pas un expert en noeud js. Donc, je ne sais pas si c'est du code propre.
Mais ça marche pour moi
Voici un petit exemple:
NODE JS
var rp = require('request-promise');
var express = require('express'),
app = express(),
port = process.env.PORT || 3000;
var options = {
method: 'POST',
uri: 'http://api.posttestserver.com/post',
body: {
some: 'payload'
},
json: true // Automatically stringifies the body to JSON
};
app.get('/', function (req, res) {
rp(options)
.then(function (parsedBody) {
res.send(parsedBody)
})
.catch(function (err) {
res.send(err)
});
});
app.listen(port);
JS
axios.get("http://localhost:3000/").then((res)=>{
console.log('================res====================');
console.log(res);
console.log('====================================');
})
Si votre serveur est une application Spring Boot, veuillez ajouter cette annotation dans la partie supérieure de votre contrôleur - @CrossOrigin
Cela devrait fonctionner maintenant. Merci
Pour le serveur Ruby on Rails dans application_controller.rb, ajoutez ceci:
after_action :cors_set_access_control_headers
def cors_set_access_control_headers
headers['Access-Control-Allow-Origin'] = '*'
headers['Access-Control-Allow-Methods'] = 'POST, GET, OPTIONS'
headers['Access-Control-Allow-Headers'] = '*'
end
Aucun en-tête 'Access-Control-Allow-Origin' n'est présent sur la ressource demandée. Origin ' https://sx.xyz.com ' n'est donc pas autorisé à accéder.
J'avais également rencontré un problème similaire avec Cross Domain Data Exchange dans la réponse Ajax, sous la forme error undefined. Mais la réponse dans l'en-tête était Code d'état: 200 OK
Failed to load https://www.Domain.in/index.php?route=api/synchronization/checkapikey:
No 'Access-Control-Allow-Origin' header is present on the requested resource.
Origin 'https://sx.xyz.in' is therefore not allowed access.
La solution pour contourner le problème: Dans mon cas, il s'agissait d'appeler la fonction checkapikey () via Ajax vers un autre domaine et d'obtenir la réponse avec les données à l'endroit où l'appel a été passé:
if (($this->request->server['REQUEST_METHOD'] == 'POST') && isset($this->request->server['HTTP_Origin'])) {
$this->response->addHeader('Access-Control-Allow-Origin: ' . $this->request->server['HTTP_Origin']);
$this->response->addHeader('Access-Control-Allow-Methods: GET, PUT, POST, DELETE, OPTIONS');
$this->response->addHeader('Access-Control-Max-Age: 1000');
$this->response->addHeader('Access-Control-Allow-Credentials: true');
$this->response->addHeader('Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With');
$headers = getallheaders();
...
}
Cette solution fonctionnera certainement pour vous. Ajouter un descripteur de message personnalisé
public class CustomHeaderHandler : DelegatingHandler
{
protected override async Task<HttpResponseMessage> SendAsync(
HttpRequestMessage request, CancellationToken cancellationToken)
{
HttpResponseMessage response = await base.SendAsync(request, cancellationToken);
var referrer = request.Headers.Referrer;
if (referrer != null && !response.Headers.Contains("Access-Control-Allow-Origin"))
{
response.Headers.Add("Access-Control-Allow-Origin", referrer.Scheme + "://" + referrer.Authority);
}
return response;
}
}
Inscrivez-vous dans webapiconfig.cs.
config.MessageHandlers.Add (new CustomHeaderHandler ());
Et si vous utilisez SignalR, ajoutez ce code dans le fichier globle.asax.cs
protected void Application_BeginRequest(object sender, EventArgs e)
{
var referrer = Request.UrlReferrer;
if (Context.Request.Path.Contains("signalr/") && referrer != null)
{
Context.Response.AppendHeader("Access-Control-Allow-Origin", referrer.Scheme + "://" + referrer.Authority);
}
}
Pour Opera (cela fonctionne de la même manière que Chrome), j'ai lancé le navigateur avec cette commande:
opera --user-data-dir="~/Downloads/opera-session" --disable-web-security
Le problème est résolu! Maintenant, je peux travailler sur un fichier HTML local (sur mon disque dur) et appeler des demandes Ajax vers des origines distantes dans le même fichier.
Note 1: Vous pouvez donner n'importe quel dossier de votre répertoire personnel sous le nom --user-data-dir.
Note 2: Testé sur Debian 8 (Jessie)/Opera 39
Lorsque vous démarrez normalement (sans les paramètres ci-dessus), la même demande tombe dans le bloc de code d'erreur.
Vous pouvez peut-être copier la ressource du serveur de production sur le serveur de développement Et avoir l'URL de la ressource pour l'ajustement dynamique. De cette façon, vous liriez toujours à partir de la même origine, ce qui éliminerait l'exception d'origine croisée.
Dans mon cas, j'utilisais Spring Boot comme service, vous pouvez ajouter des annotations cross origine sur l'opération responsable.
@CrossOrigin(origins = "http://localhost:4200")
@RequestMapping(value = "getFoo", method = RequestMethod.GET)
public ResponseEntity getFoo(){
// do something
}
J'ai créé un simple pont dans mon propre domaine qui récupère et affiche le contenu du domaine externe.
<?php
header("Content-Type: text/plain");
if (isset($_GET["cnic"]))
{
$page = file_get_contents("https://external.domain.com/api/verify/" . $_GET["cnic"]);
echo $page;
}
else
{
echo "";
}
?>
Maintenant, au lieu d'accéder à un domaine externe dans AJAX, j'ai placé l'URL de ce fichier de pont.
Vous devez ajuster le Content-Type en fonction de vos besoins. Si les données sont en JSON, utilisez header("Content-Type: application/json");
Mentionnons simplement un autre moyen de "contourner" le proxy - AJAX. Envoyez une demande à votre serveur pour récupérer les données d'une autre origine et vous renvoyer la demande.
Je préfère cette approche à JSONP car elle présente des problèmes de sécurité potentiels.
J'ai résolu ce problème en activant CORS pour l'URL du client accédant à l'API Web.
Par exemple:
[EnableCors(origins: "http://clientaccessingapi.com", headers: "*", methods: "*")]