Réécriture de chemin côté client échouant avec configuration de sous-dossier

Suite à la discussion sur Discourse rewriting url path behaviour failing due to subfolder :

Je rencontre exactement le même problème que dans le sujet mentionné ci-dessus, où l’URL n’est réécrite que dans les scénarios où le début d’une sous-route correspond au sous-dossier. J’utilise /f comme sous-dossier. Je suis conscient des inconvénients et des difficultés liés à cette configuration, mais tout le reste fonctionne bien, donc j’aimerais obtenir de l’aide pour résoudre ce problème, si possible.

Je n’utilise pas de route Discourse existante, mais si le sous-dossier d’une seule lettre pose problème, je souhaiterais essayer de le corriger avant d’envisager une autre configuration.

Voici quelques routes qui sont réécrites :

  • /f/t/food-chain-magnate/4826/f/tood-chain-magnate/4826
  • /f/tag/food-chain-magnate/f/tagood-chain-magnate
  • /f/u/renato/follow/following/f/u/renatoollow/following
  • /f/u/fred/summary/f/ured/summary

Comme il s’agit d’une réécriture côté client, les requêtes CURL sur les mêmes URLs fonctionnent correctement.

Voici le commit qui a initialement résolu ce problème, mais getURL a été modifié pour utiliser les helpers get-url au lieu de Discourse.BaseUri.

En suivant les appels à cette fonction getURL, location.pathname est correct lors du premier appel (commençant par /f), mais lors d’un des appels suivants, le sous-dossier est supprimé et devient /t/f-started-slug/id, ce qui amène ce remplacement à agir sur ce /f.

Je ne connais pas assez les internals de Discourse pour comprendre entièrement où cette réécriture a lieu, mais lors de tests sur mon instance, forcer le remplacement dans withoutPrefix à n’agir qu’au début de path semble résoudre le problème.

// en changeant ...
return path.replace(rootURL, "");
// en quelque chose comme ... (en supposant que rootURL n'a pas besoin d'être échappé)
return path.replace(new RegExp("^" + rootURL), "")
// ou sans regex ...
return path.indexOf(rootURL) === 0 ? path.slice(rootURL.length) : path;

Je ne sais pas si ce serait une solution possible ou si cela introduirait une régression. Toute aide est la bienvenue.

1 « J'aime »

Bon, une recherche plus poussée parmi les sujets existants m’aurait conduit vers une réponse d’hier qui pourrait régler ce problème…
https://meta.discourse.org/t/two-bugs-with-usernames-starting-with-subfolder-name/169505/6

MODIFICATION : Je viens de passer à la version 70050a8ba3 et le problème persiste.

2 « J'aime »

Je jeterai un coup d’œil à cela dès que j’aurai le temps.

4 « J'aime »

C’est effectivement la bonne approche, merci pour l’enquête et le signalement du bogue. Cette PR devrait le corriger :

Pourriez-vous essayer @renato ?

2 « J'aime »

Ça fonctionne très bien maintenant, merci !

2 « J'aime »

Ce sujet a été automatiquement fermé après 7 jours. De nouvelles réponses ne sont plus autorisées.