[AJAX] XmlHTTPRequest, CORS et Certificat SSL

Bonjour à tous,

Je dois développer des WebServices, les sécuriser dans un tunnel HTTPS, et y accéder depuis du JS (AngularJS) hébergé sur un autre domaine... Oui, je sais...

Quand je tappe le WSDL de mon WebService depuis un navigateur, il me demande quel certificat je veux envoyer (j'ai créé ce dernier avec OpenSSL et je l'ai chargé dans mon navigateur). Puis le serveur m'envoie à son tour son certificat, que j'accepte. A partir de là, on peut communiquer. Jusque là, tout va bien et tout me semble normal.

Maintenant, quand je veux faire l'appel à ce même WSDL depuis un JS (que j'appelle depuis un index.html en local sur file://) je récupère évidemment un objet XmlHTTPRequest, positionne withCredentials=true, j'ai positonné le Access-Control-Allow-Origin: * sur mon serveur ainsi que Access-Control-Allow-Credentials: true.

Problème : mon JS n'envoie pas le certificat client, donc le serveur... ne lui répond pas.

Existe-t-il une solution pour envoyer un certificat avec JS et accepter celui du serveur ?

Ou la seule solution pour moi est de mettre en place un proxy frontal qui s'occupe de :

1. établir le lien HTTPS/SSL avec le client
2. dispatcher vers les 2 domaines les requêtes clientes
   
   1. Pour être sécurisé de point à point, je dois pouvoir mettre en place un tunnel SSL entre mon frontal et mes 2 serveurs non ?

Par avance, merci pour vos pistes, réponses, solutions, etc...
Olivier.

http://en.wikipedia.org/wiki/Same_origin_policy

L'utilisation d'AJAX en file:// est une source infinie de problèmes... Ca me semble du reste assez hérétique conceptuellement. Tu devrais essayer depuis un serveur local, ce serait plus judicieux.
Et si l'utilisation d'un serveur local n'est pas envisageable, alors il faudra se poser la question de savoir si les technologies que tu utilises sont vraiment adaptées à ton besoin.

Salut sekaijin.

Je suis d'accord sur le principe du same origin. Qu'on peut outrepasser justement grâce à CORS.

Ma problématique est bien dans le cadre de CORS, s'il est possible d'établir une nouvelle connexion en HTTPS, et donc d'échanger des certificats, avec XmlHTTPRequest. (ou XDomainRequest).

A+

Citation:

---

Envoyé par Bovino

L'utilisation d'AJAX en file:// est une source infinie de problèmes... Ca me semble du reste assez hérétique conceptuellement. Tu devrais essayer depuis un serveur local, ce serait plus judicieux.
Et si l'utilisation d'un serveur local n'est pas envisageable, alors il faudra se poser la question de savoir si les technologies que tu utilises sont vraiment adaptées à ton besoin.

---

Salut.

L'utilisation d'un serveur local n'est pas une option mais une certitude ;)

Je passais en file:// pour aller plus vite (et un petit peu aussi parce que je n'ai pas les droits d'admin sur cette f*** machine pour m'y installer un Apache...) et parce que je ne connaissais pas de problèmes particuliers liés à ce protocole.

Je viens de récupérer une autre machine (sous Windows, c'est pratique tiens pour installer des serveurs...). J'y installe Apache et je teste. J'ai quand même peur de tomber sur le même problème, si mon JS n'est pas dans le même domaine, pour faire une appel HTTPS il faut obligatoirement que je fasse un échange de certificats. Si XmlHTTPRequest ne le permet pas...

Citation:

---

Envoyé par leminipouce

J'ai quand même peur de tomber sur le même problème, si mon JS n'est pas dans le même domaine, pour faire une appel HTTPS il faut obligatoirement que je fasse un échange de certificats. Si XmlHTTPRequest ne le permet pas...

---

Le problème n'est pas le même : la same-origin-policy n'aurait pas autorisé un fichier du disque dur à communiquer avec un site web. Les règles CORS n'outrepassent rien du tout et notamment pas ça. (Elles permettent à deux sites de communiquer s'ils sont d'accords. C'est différent.)

... Mais oui, le problème du certificat côté client, reste.
Je ne suis pas sûr de comment ça pourrait marcher, parce qu'il s'agit là d'authentifier le fait que c'est bien ton navigateur, qui appelle le site A à la demande du site B.
Et à ma connaissance, le protocole SSL ne permet pas de moyen de représenter l'autorité "client X, à la demande de domaine Y"

Citation:

---

Envoyé par thelvin

Le problème n'est pas le même : la same-origin-policy n'aurait pas autorisé un fichier du disque dur à communiquer avec un site web. Les règles CORS n'outrepassent rien du tout et notamment pas ça. (Elles permettent à deux sites de communiquer s'ils sont d'accords. C'est différent.)

---

Tu as complètement raison. J'ai pris un raccourcis erroné en parlant du même problème :oops:

Quoi qu'il en soit, je n'ai effectivement pas réussi à demander à mon JS d'ouvrir un nouveau canal SSL, alors que la problématique Cross-Domain était résolue.

J'ai donc mis en oeuvre l'autre solution que je présentais :

1. Un frontal Apache avec lequel mon client communique en HTTPS
2. 2 serveurs derrière le frontal avec lesquels il communique en HTTP
3. Quand le client lance le JS, il a déjà ouvert son tunnel SSL avec le frontal Apache.
   
   1. Mais dans tous les cas, il n'y a plus de XDomain avec JS, vu qu'il appelle lui aussi le frontal. C'est mod_proxy qui s'occupe de faire la redirection vers la bon serveur en interne...

La solution marche et je dois avouer, me plait.

Merci encore pour vos aides.
A+
Olivier.