J’ai déployé un nouveau plugin WordPress qui s’appuie sur le SSO de Discourse, mais je rencontre un étrange bug qui n’affecte que la version en production du site.
En local, je peux me connecter et utiliser le paramètre redirect_url pour revenir à la page. Cependant, sur le site en production, le SSO ne fonctionne que si redirect_url correspond à l’URL de wp-admin, par exemple :
Avez-vous déjà rencontré ce problème ? Avez-vous des pistes à explorer ? Si cela persiste, je devrai créer mon propre mécanisme de redirection pour intercepter wp-admin.
Haha, ce n’est pas ma décision, le site utilise Cloudflare comme cache principal. Je vais devoir faire des recherches sur les proxies inversés et voir si je peux ajuster certains paramètres dans CF.
Il existe des dizaines de sujets concernant les problèmes causés par les optimisations de Cloudflare. Vous pourriez utiliser Cloudflare en tant que CDN, ce qui permettrait à Discourse de ne rediriger que les éléments pouvant être mis en cache via Cloudflare.
Vous pourriez également le désactiver temporairement pour voir si cela résout le problème.
Désactivez simplement les fonctionnalités « performance » et « rocket loader » de Cloudflare pour Discourse via les règles de page, ce qui devrait très probablement régler le problème pour vous.
Oui, il s’agit d’un étrange mélange de problèmes, qui semble être en partie dû au répertoire d’installation de WP. J’ai mis en place une solution de contournement pour le moment qui redirige systématiquement vers /core/wp-admin, puis il y a un paramètre final ?final_redirect_url que mon propre hook intercepte et qui déclenche les actions nécessaires pour nous ramener à l’endroit souhaité.
Il semble que vous utilisiez WP Discourse – WordPress plugin | WordPress.org avec l’option Client SSO activée (Discourse est le fournisseur SSO). Pouvez-vous confirmer que c’est bien le cas ?