ot_typo3/doc/historic/cross_domain_auth.md

Objectif

Permettre à un site dont le nom de domaine n'est pas en ***.opentalent.fr de s'authentifier auprès de l'API opentalent.

Problème

Les navigateurs restreignent les cookies à un seul nom de domaine.

Les cookies générés par l'authentif auprès de l'api sont donc invisibles pour le site mondomaine.com

Reproduire le problème

Pour tester les solutions, il va falloir simuler un domaine différent.

Dans le cas standard, si je me rend à l'adresse , et que je me connecte en tant que opentalent74, lorsque je me rend à l'adresse , j'apparais comme connecté.

Je créé l'entrée suivante dans mon /etc/hosts:

127.0.0.1 local.sub.customdomain.fr

Je créé un certificat pour l'adresse local.sub.customdomain.fr

Je me connecte au docker nginx-proxy, et je remplace les domaines dans la conf de nginx:

sed -i 's/local\.sub\.opentalent\.fr/local.sub.customdomain.fr/g' /etc/nginx/conf.d/default.conf
nginx -s reload

Je me rend à l'adresse local.admin.opentalent.fr/#/login

Je m'authentifie en tant que opentalent74

Je me rend à l'adresse http://local.sub.customdomain.fr/ohcluses

Je ne suis pas connecté.

Solutions envisagées

1- Envoyer les cookies au site depuis l'api via un controller dédié

Lors d'une connexion réussie, l'API enverra une requête POST aux sites ayant des domaines custom et pour lesquelles le user a un Access

Un controller dédié côté Typo3 (ex: setCookies.php) génèrera ensuite les cookies avec les noms de domaines correspondant.

Pour tester cette solution, j'ajoute une requête curl dans le AuthenticationSuccessListener:

http://docker.sub.customdomain.fr/typo3conf/ext/ot_connect/setCookies.php?BEARER=' . $data['token']

Côté setCookie.php, le contenu est simplement:

setcookie('BEARER', $_REQUEST['BEARER'], 0, "/", "customdomain.fr");

Je teste, je m'assure que:

• le fichier setCookie est bien appelé: oui
• la variable $_REQUEST['BEARER'] est bien définie: oui

Je teste dans mon navigateur:

• je vide mes cookies
• je me rend à https://local.admin.opentalent.fr/#/login
• je me connecte en tant que opentalent74
• je me rend à l'adresse https://local.sub.customdomain.fr/ohcluses
• je ne suis pas authentifié, et aucun cookie n'apparait.

Raté.

2- SetCookie.php + <img>

Plus de détails sur la solution ici: https://subinsb.com/set-same-cookie-on-different-domains/

Le setcookie.php est de la forme:

setcookie('BEARER', '123456', 0, "/", "customdomain.fr");

J'ajoute la ligne suivante au front du logiciel:

<img src="http://local.sub.customdomain.fr/typo3conf/ext/ot_connect/setCookies.php" style="display:none;" />

Je teste de la même façon que pour la solution 1

Le cookie est bien présent: Yes!

2- SetCookie depuis la page de login

J'ajoute à docker/apps/opentalent-admin-2.0/src/app/config/routing/main.js, ligne 79 :

setCookie:['getOrganization', 'Restangular', function(getOrganization, Restangular){
    Restangular.oneUrl('no-x-access-id', 'https://local.sub.customdomain.fr')
        .withHttpConfig({withCredentials: false})
        .get()
        .then(resp => {
        })
}],

Afin de tester plus facilement depuis la page de login du logiciel, je modifie la ligne 14 du fichier docker/apps/opentalent-admin-2.0/src/app/ng-admin-jwt-auth/loginController.js en:

this.$state.go('switch', { organization_id: response.data.profile.organizationConnected}, {'reload':true, 'inherit':false});

Je relance le gulp serve

Le setcookie.php est de la forme:

setcookie('BEARER', 'azerty', 0, "/", "customdomain.fr");

Je teste de la même façon que pour la solution 1

(...)

Après de nombreuses tentatives et blocages (blocages CORS, variable _POST vide...) On décide de laisser tomber cette méthode pour le moment.

Solution retenue et mise en oeuvre

On récupère le champs otherWebsite de la structure(db: opentalent, table: Parameters)

Si ce champs ne matche pas la regex https?:\/\/.*\.opentalent\.fr

Alors, on insère la ligne suivante aux pages du logiciel:

<img src="https://<domain>/typo3conf/ext/ot_connect/setCookies.php?bearer=<bearer>" alt="" style="display:none;" />

où:

• <domain> est le champs otherWebsite de la table Parameters de la structure à laquelle le user est connecté
• <bearer> est le token BEARER du user connecté

Le setCookie appelé vérifie que le referer est bien en opentalent.fr. Si oui, et si la requête a un paramètre BEARER, alors il créé le cookie correspondant dans le bon domaine.

https://blog.theodo.com/2016/10/how-to-track-your-users-over-several-domains/

Update

Parce que les règles de sécurité des navigateurs ont semble-t-il encore évolué, la solution retenue et qui fontionnait n'est plus opérationnelle.

Dans l'attente d'une solution durable (serveur d'auth), on se rabat sur une solution temporaire, c'est à dire qu'on réactive les modales d'authentification sur les sites dont le domaines n'est pas en .opentalent.fr