Avec plusieurs instances Discourse configurées avec login required et utilisant SSO, nous rencontrons des redirections infinies lors de la connexion sur Safari sous iOS. Voici ce qui se produit :
L’utilisateur n’est pas connecté sur Discourse ni sur le site maître SSO.
L’utilisateur accède à une instance Discourse.
Discourse redirige vers la page SSO.
La page SSO demande les identifiants. L’utilisateur se connecte.
L’utilisateur reste bloqué dans une boucle de redirection entre le site maître SSO et Discourse, jusqu’à ce que Safari abandonne.
Si l’utilisateur accède manuellement à nouveau à Discourse, il est alors connecté.
Je ne parviens pas à reproduire ce comportement avec Chrome sur ordinateur de bureau.
Pendant qu’un client est coincé dans la boucle de redirection, plusieurs entrées Started SSO process et User was logged on sont générées, ce qui suggère que le processus SSO s’est déroulé avec succès. Cependant, après la fin du SSO, Discourse redirige l’utilisateur vers une autre page de connexion SSO au lieu de la page d’accueil.
Cela affecte également d’anciennes instances où le SSO fonctionnait parfaitement auparavant, je ne pense donc pas qu’il s’agisse d’un problème de configuration Discourse.
Quelqu’un aurait-il une idée de ce qui pourrait poser problème ?
I have seen this on sites that have the setting same site cookies set to Strict, if it is already on Lax recommend attempting to disable and see if it works around the Safari bug.
You are % correct. It was on Lax, the default. Changing it to Disabled fixed the issue immediately. (I assume this is a defense-in-depth thing, on top of your usual CSRF protections, so disabling it is not overly terrible for security?)
I’ve spent a very long time figuring out a similar issue was caused by this samsite=lax behaviour:
This fixes my issue - at least on macOS Mojave - so I assume it fixes it on iOS too. Thanks!
I’d also like to know people’s opinions on this.
What with this being the Mozilla Discourse and all, we don’t have a huge amount of traffic from Safari, so don’t want to make ourselves vulnerable to CSRF attacks for something which will benefit a very small proportion of our users.