[EXPERT’TECH] Azure ML Studio : résoudre les problèmes liés au CORS

Posté le : 28/05/2019

Partager

Découvrez comment résoudre les problèmes dues au CORS (Cross-Origin Resource Sharing) sur Azure ML Studio !

 

« Il faut 20 ans pour se construire une réputation et quelques minutes d’un cyber-incident pour la ruiner. »

Stéphane Nappo, Responsable Mondial de la Sécurité de l’Information pour Société Générale International Banking.

 

L’une des fonctionnalités les plus attrayantes d’Azure ML Studio réside dans la possibilité de transformer rapidement votre template en un service web fonctionnel. De plus, un exemple de code (en C#, Python et R) est fourni pour solliciter votre API depuis n’importe quel client moderne, ce qui le rend extrêmement facile à intégrer dans votre site web ou sur une application stockée sur votre bureau.

Cependant, il est parfois difficile pour les développeurs web de l’intégrer à une solution déjà existante. Par exemple, si votre front-end est codé en JavaScript et que vous souhaitez utiliser votre nouveau service à partir du code client, il se peut que vous rencontriez une erreur assez bizarre, dans laquelle il sera indiqué que CORS n’est pas compatible avec ce service. Comme le dit la plateforme de développement de Mozilla : « Le « Cross-origin resource sharing » (CORS) ou « partage des ressources entre origines multiples » (en français, moins usité) est un mécanisme qui consiste à ajouter des en-têtes HTTP afin de permettre à un agent utilisateur d’accéder à des ressources d’un serveur situé sur une autre origine que le site courant. Un agent utilisateur réalise une requête HTTP multi-origine (cross-origin) lorsqu’il demande une ressource provenant d’un domaine, d’un protocole ou d’un port différent de ceux utilisés pour la page courante. » (Source)

Par conséquent, la requête HTTP multi-origine est soumise à des restrictions, principalement dues à des raisons de sécurité. Autrement dit, les objets web issus d’un domaine, comme JavaScript, ne peuvent pas demander des objets en provenance d’un autre domaine (demandes de services web dans notre cas). Ça paraît bizarre non ? Etant donné que la plupart des front end modernes sont codés à partir de bibliothèques js, cela rend le service web complètement inutilisable. Cependant, comme le dit le proverbe : Quand on veut, on peut. Heureusement, il y a plusieurs moyens de résoudre ce problème, et nous allons les aborder ensemble.

 

D’abord, il est tout à fait possible de désactiver le CORS à l’aide du service de gestion des APIs. Si vous avez déjà rencontré ce problème, vous avez sûrement consulté ce post dans stackoverflow (Source). Ce dernier explique que pour autoriser CORS à utiliser le service de gestion des APIs, vous devez l’activer dans la page de configuration de l’API. Cependant, comme l’ont mentionné les utilisateurs de stackoverflow, il faut payer encore plus cher, car cela nécessite que votre service Web soit intégré à un autre service Web. En effet, cette information est vraie, et réellement dommageable. Nous n’avons plus qu’à croiser les doigts pour que cette fonctionnalité soit ajoutée en libre accès dans un avenir proche.

Ensuite, afin de respecter les restrictions AML CORS, il est possible d’héberger votre propre appli web (au lieu d’avoir un service d’emballage) par exemple, une page web ASP.NET, et utiliser votre service web à partir de là. Cette solution qu’on retrouve dans le livre officiel d’AML Studio me semble beaucoup plus attrayante. Il faut admettre que cela nécessite un peu plus de développement, mais au moins, nous pouvons héberger un autre service, sans aucun frais supplémentaire.

 

Pour résumer, nous avons deux possibilités pour déjouer cette limitation :

Vous pouvez héberger votre propre service Web, en fournissant le support CORS, qui invoquera votre service Web. Les avantages de cette solution sont les suivants : elle est plus rapide que la suivante et vous permettra de solliciter votre service pour le compte de différents clients web et mobiles. Malheureusement, cette solution n’est pas gratuite et nécessite donc un paiement supplémentaire.

Si cela ne vous convient pas, vous pouvez peut-être héberger votre propre application et invoquer votre service depuis celle-ci. Si vous êtes un travailleur acharné et raffolez de développement, cette solution s’adresse à vous. Cette dernière vous permettra de rendre votre solution plus flexible.

 

Bonne chance !

 

Traduit de l’anglais, consultez la version originale ainsi que les références utilisées dans cet article ici.

Ecrit par Alibek Jakupov.

Contactez-nous Postuler Nos offres d'emploi