Produits Entr'ouvert » w.c.s.

N'y voyant plus de malice, je « Ack »

En fait il faudrait en reparler parce que dans la pratique ça ne marche pas aussi bien que ça; l'appel ajax cors qui se fait vers http://foobar/.../menu.json, quand l'usager n'est pas déjà identifié, il y a redirection vers http://authentic/... et normalement du SSO qui se ferait tout seul, mais ce n'est pas le cas, la requête ne va pas au-delà de la première redirection (302 → authentic); il manque peut-être encore un truc côté cors mais en attendnat, ces .../menu.json, ils ne fonctionnent pas tant que l'usager ne s'est pas connecté individuellement sur les différents sites.

Est-ce que l'appel ajax est fait avec le flag withCredentials¹ à true ?

[1]: https://quickleft.com/blog/cookies-with-my-cors/

Oui; je n'ai plus le détail sous les yeux, mais en gros, j'en étais arrivé à redirection ok vers authentic, bien configuré pour lui aussi faire une redirection et pas un POST de l'assertion, mais la deuxième redirection ne passait pas l'entête "origin" comme il fallait (il y était mis "null", si je me souviens bien).

Plus fondamentalement, c'était un raccourci pratique mais maintenant qu'il ne fonctionne pas, je ne suis pas sûr que logguer la personne sur tous les services pour afficher le menu soit une super idée.

Les seules références que je trouve parlant de Origin: null disent que le cas ne se présente qu'en chargeant une page via un fichier local (file:///) je ne vois pas bien comment cela pourrait être le cas ici...

Ok bug webkit: https://code.google.com/p/chromium/issues/detail?id=154967

Mais ces tests étaient faits avec Iceweasel.

J'ai parlé trop vite, en fait c'est le comportement normal d'après la spec, on va peut-être pas pouvoir faire ce que l'on veut à part avec un header ACAO à "*".

L'extrait du ticket webkit:

#9 bbudge@chromium.org

I added the CORS redirect handling to WebKit a while back. It was only implemented for asynchronous requests.

I've been reviewing the standard and I think the code conforms to it. Here are the relevant sections:

http://www.w3.org/TR/cors/#redirect-steps
http://www.w3.org/TR/cors/#resource-sharing-check

In the above reproduction steps, the first request's URL is cross-origin, and its origin is the page URL. The response is a 302 redirect with the appropriate access-control-allow-origin="test1.example.org" header so the redirect is allowed to proceed. As part of the redirect steps, the new request origin is set to "null" and it's URL is set to the value of the Location header.

The second request generates a response. The only way this second response can pass the resource sharing check is if it contains this header:

access-control-allow-origin="*"

Furthermore, the original XHR must not have "allow-credentials" set to true.

If no header is present, or if specific origins are specified, the response is rejected. The code seems consistent with the standard here.

À la lecture je pense qu'il va aussi falloir qu'authentic et combo émettent le header Access-Control-Allow-Credentials: true.

Pour dépasser tout ça, plus fondamentalement, je reviens avec mon commentaire "je ne suis pas sûr que logguer la personne sur tous les services pour afficher le menu soit une super idée."

(et Access-Control-Allow-Credentials est déjà positionné, sinon ça ne marcherait pas même une fois loggué).

Frédéric Péters a écrit :

Pour dépasser tout ça, plus fondamentalement, je reviens avec mon commentaire "je ne suis pas sûr que logguer la personne sur tous les services pour afficher le menu soit une super idée."

Concernant les accès backoffice, ça ne me chiffonne pas beaucoup de logguer sur tous les backoffices (à moins que ta remarque exacte soit "techniquement c'est pas une super idée").

Ensuite, techniquement, s'il faut afficher un menu contextuel selon l'utilisateur et ses droits, je vois pas comment faire autrement que le loguer, ou équivalent. Tu as une autre idée en tête ?

L'alternative à laquelle je pensais c'était faire une requête ajax unique, sur le service courant (ou sur authentic en se disant que la personne y est connectée aussi), et que cet appel fasse le tour des différents services, par requêtes signées ?NameID=foobar.

La nouvelle piste est de faire du JSONP qui reste plus souple (mais moins sécurisé) que CORS.

Ack des 3