1
votes

CORS (problème d'origine croisée) lors de l'appel des services Spring Rest à partir d'Angular4

Nous avons une application frontend développée en Angular2 et les services (services REST) ​​sont développés à l'aide de Spring MVC. Lorsque l'application frontale, c'est-à-dire que javascript appelle le service, nous sommes confrontés à un problème d'origine croisée et les appels de service échouent.

Sur la recherche, il existe une option pour inclure CORSFilter du côté des services, mais l'interface utilisateur appelle environ 30 services et tous sont des déployables distincts.

Faire des changements dans 30 services n'est pas une option viable, mis à part les changements du côté des services, y a-t-il d'autres options disponibles?

Veuillez suggérer.


2 commentaires

Vous supposez d'ajouter une origine croisée à vos points d'extrémité (côté serveur). Vous devez autoriser le serveur à partir duquel vous envoyez la demande pour accéder au côté serveur. Je ne sais pas comment cela fonctionne sur JAVA, mais cherchez-le simplement sur Internet. "ajouter l'origine croisée au printemps"


exemple de code: github.com/dineshbhagat/spring-boot-cors-example


3 Réponses :


0
votes

Je pense qu'il n'y a pas d'autre moyen que d'activer CORS sur votre serveur. Vous pourriez peut-être encapsuler vos points de terminaison d'API en créant un microservice dédié et activer CORS dessus.


0 commentaires

0
votes

Il existe une solution dans Spring Boot, vous pouvez la trouver dans ce lien: https : //spring.io/guides/gs/rest-service-cors/ Je ne suis pas particulièrement sûr de ce dont vous avez besoin, mais @crossOrigin (-> Lien de votre site <-) a fonctionné de mon côté.


MODIFIER

Voici la configuration globale dans ce lien: https: // spring.io/guides/gs/rest-service-cors/#_global_cors_configuration après avoir ajouté ceci sur mon application, cela a résolu mon problème.


0 commentaires

0
votes

Je pense qu'il y a plus ici que ce que l'on voit et il est important de comprendre d'abord CORS et ensuite d'essayer de trouver des solutions au fur et à mesure que les gens apportent des mots comme - Angulaire , etc. dans la discussion CORS.

Supposons que vous ayez développé et déployé des API avec l'intention d'être consommées à partir d'un code d'interface utilisateur spécifique déployé sur certaines URL / domaines fixes . En tant que serveur, CORS est un moyen de dire aux clients (comme les navigateurs) que même si je traite cette demande, je vous dis également que cette demande ne provenait pas d'un domaine d'interface utilisateur auquel j'attendais en tant que serveur ( par par défaut - il doit s'agir de la même origine ), vous devez donc prendre les mesures nécessaires. Lorsque le navigateur est signalé par le serveur, il supprime la réponse du serveur et indique que la demande a échoué.

Ci-dessus est en effet une description très simpliste et vous devriez en savoir plus sur la politique de Sécurité de même origine .

Notez également que le serveur marque le client en définissant des en-têtes de réponse sur les origines qu'il prend en charge mais qu'il sert la réponse de toute façon, donc jusqu'à ce stade, vous devez comprendre deux points,

  1. Cela n'a rien à voir avec Angular et a tout à voir avec le navigateur
  2. C'est la prérogative du client, ce qui est fait si le serveur lui dit que la requête ne vient pas de l'origine / domaine, il attendait de. Habituellement, seuls les navigateurs Web l'implémentent et ne le font pas par des clients tels que curl , etc.

Cela dit, aimeriez-vous que vos API soient hébergées sur le même domaine que celui du domaine de l'interface utilisateur? Sinon, vous devez changer le code côté serveur pour indiquer explicitement les en-têtes CORS sinon le navigateur va continuer à échouer.

Solutions,

1.Ajoutez une annotation - org.springframework.web.bind.annotation.CrossOrigin à chacun des points d'extrémité.

2.Ajoutez une configuration globale à chaque unité déployable comme illustré ici . L'avantage étant que ces artefacts peuvent en outre être déployés dans différents domaines.

Ne vous contentez pas de copier-coller aveuglément cette ligne, config.addAllowedOrigin ("*"); , réglez-la sur le domaine spécifique que vous souhaitez servir sinon cela ne sert à rien d'avoir cette sécurité.

3.Écrivez un autre artefact déployable remettant vos éléments de sécurité comme CORS, etc. et cet artefact sera le front pour recevoir toutes les demandes entrantes et ensuite répondre après avoir construit des réponses à partir de ces 30 points d'extrémité. Les clients n'interagiraient pas directement avec ces 30 points de terminaison, mais uniquement avec cet artefact. De toute évidence, cet artefact serait également nécessaire sur le même domaine que ces 30 points d'extrémité.

Apporter des modifications à 30 services n'est pas une option viable, à part faire des changements du côté des services, y a-t-il d'autres options disponible?

Je ne pense pas qu'il y ait d'autre solution que de modifier le code côté serveur. Personne d'extérieur à votre équipe ne peut vous les dicter car le modèle de déploiement est un sujet très approprié et va par besoin par besoin d'une organisation à l'autre.

L'en-tête Origin est envoyé dans la requête et se compose des trois parties: le protocole, l'hôte et le numéro de port.


1 commentaires

Merci Sabir Khan pour l'explication détaillée. Laissez-moi essayer de mettre en œuvre les changements suggérés.