Les connexions redirigent vers une page de notifications manquante

Bonjour, nouvel utilisateur de Discourse.

Je suis sur la version 2.5.0.beta3 et j’ai personnalisé Discourse via les paramètres d’administration en apportant plusieurs modifications pour désactiver des fonctionnalités dont je n’ai pas besoin (badges, messages privés, etc.). Je n’ai apporté aucune modification au code ni à la configuration brute, et je n’utilise pas non plus de SSO.

Je ne m’en étais pas rendu compte, mais après m’être déconnecté puis reconnecté, je suis redirigé vers /notifications?recent=true&limit=5, ce qui affiche « Oups ! Cette page n’existe pas ou est privée. »

Je n’ai pas réussi à trouver le paramètre fautif qui contrôle ce comportement : mon utilisateur a la « Page d’accueil par défaut » définie sur « Catégories ». J’ai testé avec plusieurs comptes, et tous affichent le même comportement.

Toute aide serait grandement appréciée !

Nous venons de passer à la version 2.5.0.beta3 et nous rencontrons exactement le même problème.
La connexion redirige vers notifications?recent=true&limit=5 au lieu de la page d’accueil définie dans les préférences de l’utilisateur, ce qui entraîne une erreur 404.

L’URL correcte pour les notifications d’un utilisateur serait /u/nomutilisateur/notifications?recent=true&limit=5.

Quoi qu’il en soit, le système devrait prendre en compte les préférences de l’utilisateur. Il semble que la connexion ne récupère pas l’ID utilisateur (connexion avec un nom d’utilisateur), mais après la page d’erreur 404, vous êtes en fait connecté.

C’est très étrange. Je viens de mettre à jour un site et je n’ai pas ce problème.

Utilisez-vous des plugins ou des thèmes qui pourraient causer cela ? Le safe-mode résout-il le problème ?

Pouvez-vous partager l’URL de votre site ?

Aucun thème ou composant connu ne devrait avoir d’impact sur ce problème. J’ai dû désactiver un composant personnalisé qui a rompu la mise à jour de la version 2.4 vers la 2.5, mais cela est sans rapport (cela modifie la disposition des groupes en une liste).

Qu’est-ce que le « mode sécurisé » et comment l’utiliser ?

L’URL du site ne sera pas utile car il n’y a pas d’accès public.

Le mode sans échec ne semble faire aucune différence, mais je ne suis pas convaincu qu’il ait activé le mode sans échec en suivant ces instructions :

En effet, ajouter simplement /?safe_mode à la fin de l’URL du site n’a affiché aucune page d’options – il a simplement rechargé la page de connexion. De même, l’utilisation de /?safe_mode=no_custom&no_plugins&only_official a eu le même effet, et il ne semblait y avoir aucune différence sur le site.

J’ai pu activer le mode sans échec (je me suis simplement connecté et les options étaient disponibles). J’ai laissé toutes les cases cochées, déconnecté, puis reconnecté.

Après la connexion, j’ai été redirigé vers la page /notifications?recent=true&limit=5.

Pourquoi ?

Pourquoi n’est-ce pas cohérent (parfois cela mène au bon endroit) ?

Notez que cet URI se trouve dans un cookie de la page de connexion.

Des progrès ? Nous rencontrons le même problème. Cela se produit sur un serveur mais pas sur un autre serveur de test avec la même charge de plugins et de composants.

Le plugin OAuth2 a été installé sur les deux, mais il est maintenant désactivé (depuis avant la mise à niveau). Il est possible que le plugin OAuth2 ait été activé sur celui qui pose problème pendant la mise à niveau et ait été désactivé après la mise à niveau – j’attends que l’administrateur système confirme l’ordre dans lequel il a effectué les opérations.

OAuth2 a été installé pendant la mise à niveau. Il est désactivé depuis.

Avez-vous installé le plugin OAuth2 ?

Êtes-vous sur une installation dans un sous-dossier ?

Qu’est-ce qu’une installation dans un sous-dossier ?
Nous avons simplement une installation standard. Nous disposons d’un dossier containers contenant un fichier app.yml, et nous lançons Discourse en exécutant un script appelé launcher (en tant que root).

Je rencontre le même problème après la mise à niveau vers 2.5.0.beta3.
Installation standard auto-hébergée, seuls les plugins officiels sont utilisés.
Google Oauth est configuré.

Je peux confirmer que cela se produit — ou quelque chose de similaire — sur mon installation de test.


Test : https://smoke-test.redacted.invalid/
Démarrage du test de fumée Discourse pour https://smoke-test.redacted.invalid/
RÉUSSI : aller au site - 1119 ms
RÉUSSI : s'attendre à un bouton de connexion dans l'en-tête - 266 ms
RÉUSSI : ouvrir la fenêtre de connexion - 85 ms
RÉUSSI : la fenêtre de connexion est ouverte - 8 ms
ÉCHEC DE LA REQUÊTE HTTP vers https://smoke-test.redacted.invalid/notifications?recent=true&limit=5 Statut : 403
JOURNAL DE PAGE : Échec du chargement de la ressource : le serveur a répondu avec un statut 403 ()
ÉCHEC DE LA REQUÊTE HTTP vers https://smoke-test.redacted.invalid/logs/report_js_error Statut : 429
JOURNAL DE PAGE : Échec du chargement de la ressource : le serveur a répondu avec un statut 429 ()
RÉUSSI : saisir les identifiants et se connecter - 363 ms
RÉUSSI : connecté - 1606 ms

En vérifiant l’inspecteur, je vois une requête vers /notifications?recent=true&limit=5 dès que j’ouvre la fenêtre de connexion, mais aucune redirection ne se produit.

Je pense que cela vient de

D’accord, alors @featheredtoast

Un correctif rapide a été soumis :

Cela devrait apparaître dans tests-passed dans environ 15 minutes.

Je peux confirmer que la correction a résolu le problème sur mon installation.
Merci pour votre réactivité !