2016-10-30 2 views
0

J'ai une webapp printemps avec la sécurité de printemps (3.2.3, donc pas de protection CSRF) et angulaire.Spring + Angular/IE obtient 403 sur PUT (d'autres pas)

Dans un contrôleur i ont une méthode comme celle-ci pour mettre à jour les utilisateurs pw:

@RequestMapping("/accountinfo/password", method = arrayOf(RequestMethod.PUT)) 
@ResponseBody 
@Secured("ROLE_USER") 
open fun updateOwnPassword(user: User, @RequestBody password: String) { 
    val editedUser = user 
    editedUser.password = encoder.encode(password) 
    userRepository.save(editedUser) 
} 

La demande se fait via le service angulaire:

function changeOwnPassword(newPassword) { 
     return $http 
      .put('accountinfo/password', newPassword) 
      .then(function (response) { 
       return response.data 
      }); 
    } 

Cela fonctionne très bien dans tous les navigateurs i testé avec. Sauf si vous utilisez IE 11.0.35 dans un environnement Citrix (fonctionne en dehors de celui-ci, mais ne peut pas voir de configuration spécifique). Dans ce cas, je reçois 403 sur la demande. Quand je change la méthode pour POST cela fonctionne bien encore. Je pourrais le faire pour chaque fonction où j'ai eu ce problème bien sûr, mais cela ne semble pas être une solution propre. En ce qui concerne mes recherches, je pense que c'est quelque chose qui ne va pas dans la façon dont le navigateur écrit la demande, mais c'est que je ne peux pas savoir quoi faire. J'ai comparé les en-têtes de demande d'IE 11.0.35 à l'intérieur et à l'extérieur de Citrix et ils semblent exactement les mêmes. La seule différence est que la version de travail utilise DNT = 1 et la version non fonctionnelle WOW64 dans les attributs User-Agent?

MISE À JOUR: Je trouve que cela se produit avec SUPPRIMER trop

+0

Référez-vous ici: http://stackoverflow.com/questions/18172915/jquery-ajax-put-request-issue-in-internet-explorer – developer

+0

J'utilise déjà . Notez également qu'il fonctionne avec Internet Explorer en dehors de Citrix – Heady

+0

J'ai essayé cette solution de toute façon et cela n'a pas fonctionné – Heady

Répondre

0

trouvé le problème: Le client envoie les requêtes via un proxy supplémentaire qui n'aime pas PUT et DELETE et coupe juste les cookies de session hors de celui-ci . Nous abordons ce problème en plaçant les jetons dans l'en-tête dans le futur.