J’ai testé une migration de la version 4.2.4 vers la dernière version 4.3.3 et j’ai une erreur Javascript bloquante lorsque je tente d’afficher fabmanager dans un navigateur :
Uncaught Error: Plural Function not found for locale: fr
at new MessageFormat (application-b5fa11097fe38cde7dd49d80f2c74a90.js:1826)
at Object.$translateInterpolator.setLocale (application-b5fa11097fe38cde7dd49d80f2c74a90.js:1832)
at interpolationFactoryAdder (application-b5fa11097fe38cde7dd49d80f2c74a90.js:1819)
at Object.forEach (application-b5fa11097fe38cde7dd49d80f2c74a90.js:36)
at $translate.$get (application-b5fa11097fe38cde7dd49d80f2c74a90.js:1819)
at Object.invoke (application-b5fa11097fe38cde7dd49d80f2c74a90.js:37)
at application-b5fa11097fe38cde7dd49d80f2c74a90.js:37
at getService (application-b5fa11097fe38cde7dd49d80f2c74a90.js:37)
at injectionArgs (application-b5fa11097fe38cde7dd49d80f2c74a90.js:37)
at Object.invoke (application-b5fa11097fe38cde7dd49d80f2c74a90.js:37)
Pour expliquer la stack technique, je suis en environnement docker (docker-compose). Pour upgrader de 4.2.4 à la dernière version 4.3.3, j’ai suivi les étapes suivantes :
# récupération de la dernière version de l'image docker
$ docker pull docker pull sleede/fab-manager
# commandes upgrade 4.3.0
$ docker-compose run --rm fabmanager bundle exec rake db:migrate && rake db:seed
$ docker-compose run --rm fabmanager bundle exec rake fablab:fix:name_stylesheet
# commandes upgrade 4.3.3
$ docker-compose run --rm fabmanager bundle exec rails fablab:fix:avoirs_wallet_transaction
J’ai ajouté également ces lignes dans le fichier env :
TIPS:
Si je force la version à « release-v4.2.4 » dans le fichier docker-compose.yml, le site refonctionne à nouveau (sans toucher le fichier env)
Si je force la version à « release-v4.3.2 » dans le fichier docker-compose.yml, le site fonctionne également (sans toucher le fichier env) mais il y a plein d’erreurs JS :
Pas de chance, j’ai toujours des erreurs.
J’ai fais plusieurs tentatives en local (en ayant dupliqué le répertoire /apps/fabmanager du serveur sur mon pc perso) et une sur le vrai serveur et j’ai le même résultat à chaque fois.
Lorsque j’essaie de me connecter, j’ai une erreur : « Unprocessable Entity ». En voici les détails :
Voici la log générée dans « log/app-stdout.log » :
Voir la trace complète
```
Started POST "/users/sign_in.json" for 172.22.0.6 at 2020-04-08 22:51:05 +0000
Processing by SessionsController#create as JSON
Parameters: {"user"=>{"email"=>"cedric.lejalle@gmail.com", "password"=>"[FILTERED]"}, "session"=>{"user"=>{"email"=>"cedric.lejalle@gmail.com", "password"=>"[FILTERED]"}}}
Can't verify CSRF token authenticity.
Completed 422 Unprocessable Entity in 1ms (ActiveRecord: 0.0ms | Elasticsearch: 0.0ms)
</details>
Il semble y avoir un problème de validation de token CSRF.
Peut-être qu'ajouter `<%= csrf_meta_tags %>` dans le code à l'endroit opportun pourrait aider ?
Malheureusement je ne connais pas suffisamment rails pour tester rapidement, mais je peux tester des modifs en live si besoin.
Pour rappel, voici la liste exacte des commandes que j'ai lancées pour passer de ma version courante (**4.2.4**) à la dernière version (**4.3.3**) :
```bash
# pull dernière version de fabmanager
$ docker-compose pull
# stop fabmanager
$ docker-compose stop fabmanager
# suppression et recompilation des assets
$ rm -Rf public/assets/
$ docker-compose run --rm fabmanager bundle exec rails assets:precompile
# 4.3.0
$ docker-compose run --rm fabmanager bundle exec rake db:migrate && rake db:seed
$ docker-compose run --rm fabmanager bundle exec rake fablab:fix:name_stylesheet
# Ajout de configs dans le fichier "config/env"
SLOT_DURATION='60'
PHONE_REQUIRED='false'
EVENTS_IN_CALENDAR='true'
USER_CONFIRMATION_NEEDED_TO_SIGN_IN='false'
BOOK_SLOT_AT_SAME_TIME='false'
# 4.3.2 - ajout config nginx dans "config/fabmanager.conf" :
proxy_set_header X-Forwarded-Proto $scheme;
# 4.3.3
$ docker-compose run --rm fabmanager bundle exec rails fablab:fix:avoirs_wallet_transaction
# Relance des containers
$ docker-compose stop
$ docker-compose up -d
Toutes ces commandes se lancent sans erreur et se comportent a priori normalement.
Les problèmes de CSRF token viennent sûrement d’un problème avec cette config :
Tu pourrais confirmer que cela fonctionne bien en tentant de supprimer les cookies puis en regardant le détails des cookies qui seront recrées ensuite ?
Merci pour ta réponse.
J’ai fait pas mal d’essais ces 2 dernières soirées et j’ai absolument toujours le même résultat.
J’ai recopié la ligne à ajouter dans le fichier de config nginx à la main (pour éviter les caractères spéciaux « invisibles »), l’ai mise au début du bloc, au milieu, à la fin… J’ai essayé la version v4.3.4 toute fraîche… Rien n’y fait, j’ai toujours le même résultat.
Alors, j’ai peut-être quelque chose qui pourrait te parler. J’ai fait comme tu m’as demandé : suppression des cookies et je regarde ceux qui sont créés.
En version 4.3.3 ou 4.3.4, j’ai ces cookies qui sont créés dès que j’accède à la page d’accueil du fabmanager :
En effet, ça confirme ce que je pensais plus tôt. En fait, lors de la mise à jour à la v4.3.2 ce cookie a été renommé en _Fab-manager_session. En 4.2.4, il devrait donc apparaître dans ta console sous ce nouveau nom. Du coup, s’il n’apparaît pas il est plus que probable que ce soit à cause de nginx : en effet, si la fameuse directive proxy_set_header X-Forwarded-Proto $scheme; n’est pas installée dans la configuration, nginx ne transférera pas le cookie au client…
Du coup j’insiste mais je pense vraiment que le problème vient de là
Tu pourrais mettre ta conf nginx ici par hasard ?
</details>
On y voit bien la directive ` proxy_set_header X-Forwarded-Proto $scheme;` mais maintenant que j'y pense, j'ai, en plus de la stack docker du fabmanager, un autre nginx qui sert de reverse proxy. Il faut peut-être que j'intègre la directive également quelque part sur mon reverse proxy ? Je trouve ça étrange mais je vais jeter un oeil et tenter le coup.
Cédric.
===========================================
**EDIT**
Je viens de faire les essais en rajoutant la directive sur le nginx reverse proxy. No luck.
J'ai testé en local en dupliquant "/apps/fabmanager" du serveur vers mon PC. Pas de reverse proxy et exactement la même anmalie.
Je pense avoir tout tenté pour l'upgrade, j'y ai passé de nombreuses heures.
Je vais passer sur un test d'installation de zéro dans une VM (virtualbox) juste pour voir si cela vient de la config ou de données de mon installation existante (un truc en base, je ne sais pas).
Mauvaise nouvelle. Avec une installation de zéro, j’ai exactement le même problème !
Comment puis-je être aussi poissard ? :slight_smile
Protocole :
J’ai créé une VM Ubuntu 18.04 server sur Virtualbox pour garantir une sandbox propre.
J’ai installé docker et docker-compose.
J’ai lancé le script d’installation de fabmanager et suivi les étapes :
\curl -sSL prepare-vps.sleede.com | bash
La première installation a planté parce que j’avais mis un mot de passe à mon utilisateur admin qui ne respectait pas les règles de base (minimum 8 caractères) mais le script ne m’a pas bloqué et a planté plus tard lors d’exécution de requêtes SQL… j’ai supprimé tout le répertoire /apps/fabmanager et recommencé à zéro. Et tout a été OK, pas d’erreur
Amélioration : ne pas continuer le process si le mot de passe ne respecte pas les règles de sécurité ?
Attention : je n’ai pas modifié le fichier « config/env » hormis l’ajout de « SECRET_KEY_BASE ». En clair j’ai laissé toutes les autres clefs à la valeur par défaut telles que récupérées depuis le template par le script d’installation.
Démarrage : OK. Je vois la page d’accueil… mais… je vois aussi dans les dev tools de Chrome la fameuse ligne « 422 Unprocessable entity ».
Je tente de me logger avec le compte admin :
J’arrête tout (docker-compose stop), je mets le fichier de config que j’ai de mon serveur qui fonctionne en 4.2.4 et je redémarre. Même erreur.
Sur mon installation de zéro je n’ai pas activé le SSL. Aucune installation de letsencrypt, je veux faire au plus simple, je suis sur un PC sans nom de domaine. Est-ce-que cela peut expliquer le problème ?
En tous cas en installant de zéro ou en upgrade j’obtiens exactement le même résultat. Honnêtement si tu as une autre piste je suis preneur. Cette fois je n’ai plus d’idée en tête pour avancer
Merci beaucoup à nouveau et désolé pour le temps passé sur ce sujet !
Effectivement c’est bien vu ça, je vais le rajouter, merci !
Concernant ton problème, ta config m’a l’air correcte. Du coup, effectivement il faut que tu rajoutes la directive en question sur ton autre nginx.
Sur ta VM, ça ne peut pas marcher sans HTTPS car, justement, la modification de la v4.3.2 était pour ajouter l’attribut « Secure » au cookie de session, ce qui évite une vulnérabilité XSS. Le seul moyen que cela fonctionne sans HTTPS est d’utiliser un environnement de développement mais je ne te le conseille pas vraiment, ça te prendrait beaucoup de temps sans t’apporter grand chose.
À mon avis, il doit y avoir une raison (obscure je l’avoue) pour laquelle ton 2e nginx ne veut pas accepter le header…
Peux-tu essayer de squeezer ton 2e nginx, au moins temporairement, pour voir si celui de FM envoie correctement le cookie ?
== Edit
En fait, si tu t’y connais un peu en nginx, tu peux carrément ne pas utiliser le nginx fourni par FM et utiliser directement le tient, en utilisant l’option « ne pas utiliser nginx » lors de l’installation. Après tu n’as plus qu’a reporter les éléments de configuration dans ton nginx et à configurer ton propre let’s encrypt pour avoir un certificat ssl valide (tu peux utiliser docker pour cela, en t’inspirant de ce que fait notre script d’installation ici puis là)
Je viens vers toi avec de bonnes nouvelles. L’upgrade en v3.4.4 est passée \o/
Voici ce que j’ai dû faire (en plus du reste déjà expliqué dans mes précedents messages) :
En revanche je me heurte à un nouveau problème, désolé…
Je peux me connecter avec un compte utilisateur sans aucun problème. Pas d’erreur JS, on est clean, tout a l’air de fonctionner !
Mais avec le compte administrateur, je n’y arrive plus :
Je ne comprends pas où je dois cliquer, je ne vois pas de lien sous le formulaire, je suis un peu paumé :-\
Peux-tu m’expliquer ce que cela signifie s’il te plaît et comment je peux faire pour me connecter avec mon compte admin ?
Merci à nouveau pour ton aide précieuse et ton temps !
Le fait que tu aies insisté sur les confs NGINX a permis de régler le problème, énorme bravo et merci !!!
Pour ton problème de validation des comptes admin, il faut que tu joues avec la variable USER_CONFIRMATION_NEEDED_TO_SIGN_IN, et que tu recompiles les assets à chaque fois que tu changes cette valeur.
Dans ton cas, si tu as le message mais pas le lien, cela veut certainement dire que ta variable est à true mais que les assets n’ont pas été recompilés depuis le passage à true.
mais je pense vraiment que le problème vient de là 
