Erreur d'authentification Google

Soutien
1

Bonjour,

Je suis nouveau sur Discourse. J’ai récemment créé un forum et je suis actuellement en train de migrer le site et le forum vers un nouveau nom de domaine.

Ancien domaine du forum : https://forum.skymail.app (inactif, redirige vers le nouveau site)

Nouveau domaine : https://forum.sugarmail.app (opérationnel)

Je rencontre des problèmes avec l’authentification Google. J’ai un projet Google Cloud et, après avoir basculé vers le nouveau domaine, j’ai également modifié l’URL de redirection sous Client ID ; elle est actuellement définie sur :

https://forum.sugarmail.app/auth/google_oauth2/callback

Voici le problème : lorsque j’essaie de « s’inscrire avec Google », j’obtiens cette erreur dans Discourse :

https://forum.sugarmail.app/auth/failure?message=csrf_detected L'autorisation a expiré ou vous avez changé de navigateur. Veuillez réessayer.

Lorsque le forum était sous l’ancien domaine, forum.skymail.app, l’authentification Google fonctionnait sans problème.

J’ai bien exécuté ./launcher rebuild app après avoir changé le domaine, en m’assurant de mettre à jour le domaine dans app.yaml sous DISCOURSE_HOSTNAME (en fait, le forum ne se chargeait pas du tout avant que je ne le fasse).

Avez-vous des pistes à me suggérer ?

2

Normalement, lorsque vous lancez le processus de connexion, le cookie _forum_session est défini dans votre navigateur. Cependant, sur votre site, cela ne semble pas se produire.

Avez-vous des plugins ou des proxys qui pourraient interférer avec les cookies de votre site ?

3

Merci pour votre réponse.

Plugins : non, je n’en utilise aucun. La seule chose que j’ai faite après l’installation a été d’activer l’authentification Google (client ID et secret) et d’activer « toujours utiliser HTTPS ».

Proxies : j’utilise nginx comme proxy inverse (qui sert également le site principal de l’application).

    # discourse
    location / {
            proxy_set_header X-Real-IP $remote_addr;
            proxy_pass_request_headers on;
            proxy_pass http://localhost:10080;
    }

et dans containers/app.yaml :

expose:
  - "10080:80"   # http
  - "10443:443" # https

Let’s Encrypt n’est pas activé dans les paramètres de Discourse. Ainsi, le nginx à l’intérieur du conteneur sert du HTTP simple, tandis que le nginx externe gère la terminaison SSL.

C’est presque la même configuration que celle que j’avais avec l’ancien domaine, la seule différence étant « forcer HTTPS ».

J’exécute la version 2.6.0.beta3.

4

Ah zut, c’est « force https » que j’avais précédemment désactivé.

Je l’ai activé récemment pour éviter l’avertissement de Chrome concernant le « contenu de page non sécurisé », qui apparaissait en raison de liens HTTP simples vers des images.

Pour réitérer, je gère la terminaison SSL dans le « nginx externe », et du côté de Discourse lui-même, il n’y a pas de SSL.

Désactiver « force https » fait à nouveau fonctionner l’authentification Google (j’ai dû ajouter une URL de redirection HTTP simple dans le projet Google Cloud).

Mais ce n’est pas idéal, car des avertissements de « site non sécurisé » ou de contenu mixte apparaîtront dès qu’il y aura des images.

Existe-t-il un moyen de maintenir l’authentification Google fonctionnelle avec « force https » et une terminaison SSL en dehors de Discourse ?

( J’aurais utilisé le support SSL natif de Discourse, mais il suppose qu’il « possède » le domaine, ce qui m’obligerait à configurer une adresse IP supplémentaire pour ce VPS et à séparer le site principal du forum… ce qui est un peu fastidieux… )

5

Assurez-vous d’envoyer X-Forwarded-Proto: https.

6

Merci @riking. J’ai maintenant copié le bloc nginx de votre lien à l’identique, puis j’ai activé « force https » comme recommandé par la console d’administration de Discourse.

Mon forum est de nouveau opérationnel et l’authentification Google fonctionne.

Cependant, un problème persiste :

Chrome et Firefox m’affichent tous deux des avertissements concernant du contenu de page non sécurisé.

En examinant la trace réseau dans les outils de développement de Chrome, il s’agit de ce lien (http simple, pas https) :

http://forum.sugarmail.app/uploads/default/optimized/1X/_129430568242d1b7f853bb13ebea28b3f6af4e7_2_512x512.png

7

Ah, peu importe. Je viens de définir une nouvelle favicon personnalisée et elle est désormais chargée via https. Plus d’avertissements de « contenu mixte ».

Superbe, merci pour votre aide !