Hypertopic
The browser should not loose the session
Reproduction scenario
- Visit Porphyry with Safari.
- Log in as an existing user.
- Click on a link or refesh the page.
Cause
Safari has a weird default security setting (different from Chrome and Firefox) that does not allow to create a cookie on a cross-domain service.
We see no solution yet (except from the workaround).
Workaround
In Safari privacy settings, uncheck "Block multi-domain cookie tracking" :
Phase 1
- [ ] Scenarios (Gherkin)
- [ ] Implementation strategy
Phase 2
- [ ] Acceptance tests (Capybara)
- [ ] Implementation
StackOverflow states that it would be fixed if Porphyry and Argos were on subdomains of the same domain.
It could be a problem also in Chrome in february 2020: https://blog.chromium.org/2020/01/building-more-private-web-path-towards.html
This is now the same with Firefox : http://mzl.la/1BAQzYZ The workaround doesn't seem to work...
As for Chrome it seems to need an additional HTTP header and the use of HTTPS : https://digiday.com/media/what-is-chrome-samesite/
Synthèse du problème d'authentification sur différents navigateurs :
-
Firefox (c'est le navigateur que j'utilise personnellement, donc je ne suis pas sûr qu'il soit dans la configuration de base) : authentification fonctionnelle.
-
Chrome : déconnecté à l'actualisation de la page ou en cliquant sur un item, même en autorisant tous les cookies...
-
Microsoft Edge : idem
-
Opera : idem
-
Internet explorer : Porphyry = page blanche
Merci @jejroux
Comme cela est susceptible de changer avec les versions, il faudrait indiquer la dernière version pour chaque navigateur.
Par ailleurs, ce serait plus visuel dans un tableau (en MarkDown) et avec un symbole visuel (ex : ✅❌). Dans le cas où ça dépend de la configuration, on pourra ajouter l'élément de configuration à changer.
J'ajouterai Safari si vous n'avez pas le moyen de le tester.
Note : Internet Explorer a été remplacé par Edge. Inutile de le mentionner parmi les navigateurs actuels. On sait qu'il n'est plus compatible avec la plupart des sites modernes.
| Navigateur | Authentification fonctionnelle | Commentaire |
|---|---|---|
| Chrome 86.0.4240.183 | ❌ | Non fonctionnelle avec tous les cookies autorisés |
| Safari 14.0 | Si suivi sur plusieurs domaines autorisé | |
| Firefox 85.0 | ✔ | |
| Edge 86.0.622.58 | ❌ | Non fonctionnelle avec tous les cookies autorisés |
| Opera 72.0.3815.186 | ❌ | Non fonctionnelle avec tous les cookies autorisés |
@jejroux J'ai ajouté Safari et trié les navigateurs en fonction de leur part de marché (en France).
N'oubliez pas de préciser les versions testées.
Non fonctionnelle avec tous les cookies autorisés
@jejroux Ce n'est pas tant les cookies qu'il faut autoriser que le "cross-domain tracking".
@benel Le fait d'autoriser les "cookies tiers" n'implique-t-il pas que le "cross-domain tracking" est autorisé ?
@benel Le fait d'autoriser les "cookies tiers" n'implique que le "cross-domain tracking" est autorisé ?
On est d'accord que les formulations sont assez difficiles à interpréter (d'autant plus qu'elles diffèrent souvent en français et en anglais)... Mais dans Safari en tout cas, un seul des deux paramètres a un effet.
Je viens de m'apercevoir que sur Chrome, Edge et Opera, il suffit d'attendre quelques temps pour être déconnecté, sans même rafraichir la page ou faire une autre action.
Je viens de m'apercevoir que sur Chrome, Edge et Opera, il suffit d'attendre quelques temps pour être déconnecté, sans même rafraichir la page ou faire une autre action.
Le problème dont on parle n'est-il pas au contraire celui de la perte de connexion (quand par exemple, on clique sur l'une des vignettes) ?
Pardon, je viens de comprendre... Oui, effectivement c'est équivalent comme test : c'est la création de session vers Argos depuis Porphyry qui est bloquée. Donc lors de la mise à jour automatique de l'affichage des données, on voit l'état réel (et non l'état "REACTif").
Je ne suis pas sûr d'avoir bien compris ce qui était voulu mais voici les scénarios déjà existants qui montrent que l'utilisateur n'est pas réellement connecté (donc finalement qui ne font qu'actualiser la vue) auxquels on peut donc ajouter le fait d'attendre la mise à jour automatique de l'affichage des données :
-
Le scénario de check_same_name_items.feature
-
Le scénario de items_with_same_attribute_value.feature
-
Le scénario de items_with_same_topic.feature
-
Le scénario de portfolio_search.feature
-
Pour tous les scénarios où il faut qu'un utilisateur soit connecté, ils ne sont pas réalisables puisque l'utilisateur n'est pas réellement connecté (et ne peux donc pas accéder par exemple à la création d'un item)
Pour tous les scénarios où il faut qu'un utilisateur soit connecté, ils ne sont pas réalisables puisque l'utilisateur n'est pas réellement connecté (et ne peux donc pas accéder par exemple à la création d'un item)
Cette phrase est correcte. Les autres, non.
Comme vous le dites, ce sont tous les scénarios qui requièrent une connexion qui vont poser problème, puisque contrairement à ce que pourrait laisser penser l'affichage immédiat, l'utilisateur n'est pas réellement connecté : https://github.com/Hypertopic/Porphyry/search?q=connecté
Comme vous le dites, ce sont tous les scénarios qui requièrent une connexion qui vont poser problème, puisque contrairement à ce que pourrait laisser penser l'affichage immédiat, l'utilisateur n'est pas réellement connecté :
Normalement, vous devriez avoir confirmation quand vous lancerez les tests automatisés.
Notez que si c'est Docker qui vous ralentit dans la mise en place des outils, vous n'en avez plus besoin depuis la mise à jour de Windows 10 en mai. WSL2 fonctionne très très bien pour installer des outils GNU sous Windows.
J'essayais en effet de comprendre le fonctionnement de docker... Je vais donc maintenant essayer de comprendre comment utiliser WSL2 pour les tests de Porphyry.
Comme prévu, tous les tests pour lesquels un utilisateur doit être connecté ont échoué (https://github.com/Hypertopic/Porphyry/search?q=connecté).
J'ai donc testé manuellement l'authentification sur le serveur Argos en HTTPS hébergé par l'UTT (https://argos.utt.fr/) qui mène à une erreur (sur Firefox) :
Suite à cette erreur, j'ai essayé de passer mon localhost en HTTPS à l'aide de cette discussion sur Stackoverflow, mais j’aboutis à la même erreur.
Suite à cette erreur, j'ai essayé de passer mon localhost en HTTPS à l'aide de cette discussion sur Stackoverflow, mais j’aboutis à la même erreur.
Par rapport au principe de base, il y a pas mal de paramètres qui peuvent expliquer l'erreur (ports entrants, ports sortants...). Merci de préciser chaque commande avec ses paramètres ainsi que l'URI testée.
J'ai téléchargé et décompressé ngrok comme conseillé sur la discussion stackoverflow, j'ai ensuite fait un npm start dans ma console Ubuntu, puis la commande suivante dans ngrok : ngrok http 3000 -bind-tls=true.
Ensuite pour accéder à Porphyry en https, j'ai du me connecter à l'URI suivante : https://d9dc30136425.ngrok.io/ qui m'est donnée par ngrok. Mais le CORS n'accepte pas cette URI.
Mise à jour du tableau de compatibilité : Ça fonctionne encore avec Firefox 85.0
Élément supplémentaire pour "raconter" les différents changements :
On aurait pu croire que le passage en https (et donc la signature cryptographique) de Porphyry aurait pu suffire pour rassurer le navigateur sur le fait qu'il est bien l'origine autorisée par Argos. Cependant c'était sans compter sur un critère de sécurité plus ancien intégré aux navigateurs qui est que l'on ne peut pas charger des éléments non sûrs à partir d'une page sûre.
Message de Safari :
The page at <PORPHYRY> was not allowed to display insecure content from <ARGOS>.
Message de Firefox :
Blocage du chargement du contenu mixte actif (mixed active content) <ARGOS>.
Message de Chrome :
The page at <PORPHYRY> was loaded over HTTPS, but requested an insecure resource <ARGOS>.
This request has been blocked; the content must be served over HTTPS.
@jejroux Je ne sais si vous aviez vu, mais il y a une très bonne explication du problème dans un petit encadré de la version anglaise de la page que nous avons souvent regardée ensemble : https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite
Il y a aussi au bas de la page un tableau de compatibilité des deux nouveaux comportements Defaults to Lax et Secure context required. Pour ces deux lignes, on retrouve à peu près ce que l'on avait indiqué dans notre propre tableau :
- Chrome (>=80), Edge (>=80) et Opera (>=67) sont passé du côté vert,
- Firefox l'est uniquement sur demande de l'utilisateur,
- par contre ils se trompent sur Safari (puisque la fonctionnalité est en place par défaut mais qu'on peut la désactiver) mais c'est peut-être parce qu'ils n'en ont pas eu un sous la main récemment.
En effet la page en anglais est très intéressante et plus complète que celle en français... Merci pour cette découverte ! Et oui c'est rassurant que les tableaux soient à peu près les mêmes que le notre. Est-ce qu'il est possible que votre paramétrage de Safari ne soit pas le paramétrage par défaut ?
Est-ce qu'il est possible que votre paramétrage de Safari ne soit pas le paramétrage par défaut ?
Le paramétrage "laxiste" que j'ai mis moi-même, oui, mais le "strict" que l'on a indiqué dans le tableau, c'est bien celui par défaut. Il est arrivé tout seul, un beau matin, après une mise à jour de Safari.
De toute manière si Safari était dans le même cas que Firefox, il serait vert avec un drapeau. Je pense que la colonne de Safari n'a pas été mise à jour récemment.
Le problème (avec Chrome et Safari) est désormais résolu grâce :
- à la modification de AAAforREST (https://github.com/Hypertopic/AAAforREST/commit/e5e459fb536d5976f9fe6a653db2793b57fde054) par @jejroux et à son utilisation devant Argos,
- à la mise en place d'un reverse proxy 'https' (avec la directive
RequestHeader set X-Forwarded-Proto "https") par la direction du numérique de l'UTT.
Merci à eux !
À noter également :
- tous les tests automatisés ont été modifiés en conséquence,
- nous avons profité de l'occasion pour passer Porphyry en https (ce qui a nécessité de passer également Steatite en https).
Using https is no more enough for Safari privacy settings. Authentication is broken again on Safari unless you uncheck "Block multi-domain cookie tracking".
Everything is still OK with Chrome and Firefox.
Here is an update of browsers allowing secure cross-domain cookies :
| Browser | HTTPS | HTTP on localhost |
|---|---|---|
| Chrome 100 | ✔ | ❌ |
| Safari 15 | If cross-domain tracking is allowed | ✔ |
| Firefox 99 | ✔ | ✔ |