67 votes

Set-Cookie dans l'en-tête HTTP est ignoré avec AngularJS

Je suis en train de travailler sur une application basée sur AngularJS sur le côté client et Java pour mon API (Tomcat + Jersey pour WS) sur le côté serveur.

Le chemin de mon API sont limités, si l'utilisateur ne dispose pas d'une session à l'état de la réponse renvoyée est 401. Sur le côté client, d'état http 401 sont interceptés pour rediriger l'utilisateur vers la page de connexion.

Une fois l'utilisateur authentifié, j'ai créer une session sur le serveur

httpRequest.getSession(true);

et la réponse de l'envoyer au client de n'avoir le Set-cookie instruction dans son en-tête :

Set-Cookie:JSESSIONID=XXXXXXXXXXXXXXXXXXXXX; Domain=localhost; Path=/api/; HttpOnly

Le problème est que le cookie n'est jamais mis sur le côté client. Quand j'ai inspecter cookie de domaine localhost c'est vide, alors la prochaine demandes n'ont pas ce cookie dans son en-tête et côté client ne pouvais toujours pas accès restreint chemin de mon API.

Le client et le serveur sont sur le même domaine, mais ils n'ont pas le même parcours et le même numéro de port :

Client : http://localhost:8000/app/index.html

Serveur : http://localhost:8080/api/restricted/

Informations supplémentaires : la SCRO est activé sur les deux côtés :

"Access-Control-Allow-Méthodes", "GET, POST, les OPTIONS"
"Access-Control-Allow-Origin", "*"
"Access-Control-Allow-Pouvoirs", true

Une idée pour faire le Set-cookie fonctionne correctement ? Est-il un AngularJS question connexe ?

21voto

Romain Lefrancois Points 136

J'ai trouvé un problème dans AngularJS qui m'aident à aller de l'avant.

Il semble qu' "Access-Control-Allow-Credentials" : true n'a pas été mis sur le côté client. L'Instruction $httpProvider.defaults.withCredentials = true a été ignorée.

Je remplace $ressource appel par un simple $http call avec {withCredentials:true} dans le fichier de configuration de paramètre.

Mais maintenant j'ai un autre problème, il semble interdit d'avoir "Access-Control-Allow-Origin", "*"et "Access-Control-Allow-Credentials", true dans le même temps. Chrome me jeter une erreur dans la console :

Ne peut pas utiliser des caractères génériques dans Access-Control-Allow-Origin lorsque les informations d'identification le drapeau est vrai.

Je suis coincé. Je ne peux pas mettre une autre origine que le générique parce que AngularJS est sur le côté client, donc je ne sais pas l'origine et je dois mettre en Access-Control-Allow-les informations d'Identification afin d'avoir des cookies.

Toutes les idées pour permettre à la fois de ces en-têtes dans le même temps ?

18voto

domokun Points 747

J'ai réussi à résoudre un problème très semblable à la vôtre. Mon Jeu! backend essayé de mettre un Cookie de session qui je n'ai pas pu Angulaire ou en magasin via un navigateur.

En fait la solution: un peu de ceci et un peu de cela.

En supposant que vous avez résolu la question initiale, qui peut être résolu que par l'ajout d'un domaine spécifique de l'Access-Control-Allow-Origin et en supprimant le générique, les prochaines étapes sont:

  1. Vous devez supprimer le HTTP-Seulement de l' Set-Cookie - tête, sinon vous ne serez jamais en mesure de recevoir un cookie "généré" par votre angulaire code
    Cette configuration sera déjà travailler dans Firefox, mais pas dans google Chrome

  2. Pour le faire fonctionner pour Chrome, vous devez:

    a) d'envoyer un autre domaine à partir de localhost dans le cookie, en utilisant le domaine de votre WS sont "hébergés". Vous pouvez même utiliser des caractères génériques comme .domain.com au lieu de ws.domain.com

    b) ensuite, vous aurez besoin de faire un appel pour le domaine spécifié dans le cookie, sinon Chrome de ne pas stocker vos cookies

    [facultatif] je suis d'avis de le supprimer /api chemin à la faveur d'un /


Et qui doit le truc.
Espère avoir été d'une aide

8voto

Joop Eggen Points 30166

L'addition HttpOnly signifie que le navigateur ne doit pas laisser les plugins et JavaScript voir le cookie. Ceci est une convention récente pour une navigation plus sûre. Devrait être utilisé pour J_SESSIONID mais peut-être pas ici.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X