2
votes

Demande CORS non valide pour PUT avec AngularJS

J'ai un mappage dans mon application Spring qui ressemble à ceci:

$http({
   method: 'PUT',
   url: 'https://localhost:8000/api/test',
   data: senddata,
   params:{'id':id},
   headers: {
     "Content-Type": "application/json; charset=utf-8"
   }
})

Lorsque vous essayez d'appeler ce point de terminaison avec Angular en faisant:

@PutMapping(path="/test/{id}")
public @ResponseBody Shop putTest(@PathVariable("id") long id,
                                  @RequestBody User user {
....

Y a-t-il un problème avec ma demande, si oui, comment puis-je y remédier?

javascript spring-boot angularjs

1 commentaires

en plus des réponses ci-dessous, dans $ http, n'utilisez pas de paramètres. utilisez comme url: https: // localhost: 8000 / api / test / $ {id} ,

3 Réponses :

2
votes

votre backend doit savoir d'où viennent les demandes. juste pour que vous testiez cette requête, vous pouvez préciser d'où provient la requête, ajoutez simplement cette anotation.

@CrossOrigin(origins = "http://localhost:9000")
@PutMapping(path="/test/{id}")
public @ResponseBody Shop putTest(@PathVariable("id") long id,
                                  @RequestBody User user {
....

j'espère que cela sera utile

1 commentaires

... ou cela peut également être fait sur le contrôleur ou même au niveau global: spring.io/guides/gs/rest-service-cors/… selon la granularité que vous attendez des restrictions

0
votes

Il s'agit d'un comportement normal lorsque l'origine n'est pas bien définie.

Regardez la configuration côté serveur. Les navigateurs envoient une demande OPTIONS avant votre demande PUT.

En savoir plus sur les en-têtes Access-Control-Request- * .

0 commentaires

1
votes

Votre application Spring est probablement diffusée sur un port différent de votre application angulaire? Pour le navigateur, cela compte comme une origine différente et donc les demandes échoueront à moins que les réponses du serveur ne contiennent un en-tête Access-Control-Allow-Origin. Vous devrez configurer votre application Spring en conséquence.

Il s'agit de la politique de même origine du navigateur, qui protège à nouveau les utilisateurs contre la falsification des demandes intersites. Par exemple. Imaginez qu'un cerveau maléfique crée un site Web apparemment innocent appelé evil.com, qui déclenche une charge de requêtes AJAX à divers serveurs bancaires en espérant que vous êtes connecté à l'un d'entre eux (c'est-à-dire que vous avez un cookie non expiré). À moins que les serveurs des banques n'aient leur en-tête de contrôle d'accès défini pour autoriser les demandes de n'importe où (ils ne devraient pas), les demandes devraient échouer. Une requête GET réussira en réalité car le navigateur ne sait pas qu'il n'aurait pas dû l'envoyer tant qu'il n'a pas récupéré les en-têtes de la réponse, mais le navigateur arrêtera le code JS de lire la réponse, donc c'est OK. Pour les demandes «non sécurisées» comme POST et PUT, etc., le navigateur fait d'abord une demande de pré-vol (en utilisant la méthode OPTIONS) pour obtenir les en-têtes. Si le domaine à partir duquel la page est chargée n'est pas inclus dans la liste des origines autorisées, la demande non sécurisée n'est pas effectuée.

0 commentaires