Cross-Origin-Resource-Sharing (CORS) sur la plateforme K5 de Fujitsu

2017-03-24

Machine-translated — the English original is authoritative.

Tous les développeurs qui ont migré le développement de leur application front-end depuis un environnement de production où vous êtes dans le même domaine, par exemple https://allthingscloud.eu, vers un environnement local de « bureau » où vous effectuez désormais des requêtes depuis http://localhost, sont familiers avec cette erreur :

Il s'agit d'un mécanisme de sécurité intégré dans la quasi-totalité des navigateurs web modernes, conçu pour prévenir les attaques malveillantes telles que le cross-site-scripting (XSS).

Il existe deux façons de relever ce défi, à condition d'avoir un besoin légitime de travailler entre différents domaines :

Activer le support CORS sur votre serveur cible – si vous possédez ou avez accès au serveur web concerné, vous pouvez activer le CORS sur le serveur web via quelques en-têtes (HEADERs) de base. Il y a un excellent article de blog ici qui couvre les exigences relatives aux en-têtes ; veuillez vous assurer de ne pas mélanger vos en-têtes client et serveur, sinon vous risquez une longue nuit de débogage ! Cependant, si le serveur cible ne prend pas en charge le CORS ou si vous n'avez pas la permission d'apporter les modifications, vous aurez besoin d'une autre solution de contournement, telle que….
Serveur proxy CORS – il s'agit d'un serveur simple qui écoute les requêtes de votre navigateur web puis relaie simplement la même requête en tant que serveur plutôt qu'en tant que navigateur, contournant ainsi complètement le problème CORS. C'est une approche de type « homme du milieu » (man-in-the-middle), mais à des fins louables 🙂

Les points de terminaison (endpoints) de l'API K5 de Fujitsu ne prennent pas actuellement en charge le CORS, c'est pourquoi j'ai opté pour un proxy CORS lors de mon récent défi de développement. C'est beaucoup plus simple que cela n'en a l'air, surtout si vous aimez travailler avec NodeJS. De nombreux modules NPM sont disponibles et nécessitent seulement une ou deux lignes de code pour implémenter un serveur proxy CORS. Par exemple, corsproxy et corsproxy-https. Cependant, après quelques tests, je me suis décidé pour le module cors-anywhere car ce module transmet à la fois le corps de la réponse http ET les en-têtes de réponse… quelque chose que tous les proxies ne se donnent pas la peine de faire.

Le serveur proxy simple ressemble à ceci :

Ce fichier contient des caractères Unicode cachés ou bidirectionnels qui peuvent être interprétés ou compilés différemment de ce qui est affiché ci-dessous. Pour les examiner, ouvrez le fichier dans un éditeur qui révèle les caractères Unicode cachés.
En savoir plus sur les caractères Unicode bidirectionnels

Afficher les caractères cachés


	// Heroku définit la variable d'environnement PORT, et exige que l'adresse de liaison soit 0.0.0.0
	var host = process.env.PORT ? '0.0.0.0' : '127.0.0.1';
	var port = process.env.PORT

	var cors_proxy = require('cors-anywhere');
	cors_proxy.createServer({
	originWhitelist: [], // Autoriser toutes les origines
	//requireHeader: ['origin', 'x-subject-token'],
	}).listen(port, host, function() {
	console.log('Exécution de CORS Anywhere sur ' + host + ':' + port);
	});

voir le code brut
cors_proxy_service.js
hébergé avec ❤ par GitHub

L'application Angular 2 où je l'ai utilisé peut être téléchargée ici – https://github.com/allthingsclowd/K5_Angular_2_Example_Login

Happy Stacking !

withk5youcan

Originally published on allthingscloud.eu (2017-03-24).