Erreurs upgrade 4.2.4 > 4.3.3 (docker)

Bonjour,

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 :

SLOT_DURATION=‹ 60 ›
PHONE_REQUIRED=‹ false ›
EVENTS_IN_CALENDAR=‹ true ›
USER_CONFIRMATION_NEEDED_TO_SIGN_IN=‹ false ›
BOOK_SLOT_AT_SAME_TIME=‹ false ›

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 :

Si vous avez des idées de comment faire fonctionner l’upgrade, je suis preneur !
En attendant je reste en 4.2.4.

Merci beaucoup pour votre aide.

Cédric Le Jallé

Salut,

As-tu lancé les commandes pour supprimer et recompiler les assets ?
Voir les points 4 et 5 de la procédure.

Tiens nous au courant.

Bonne journée,

Bonsoir @Sylvain

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)

ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken):

actionpack (5.2.4.2) lib/action_controller/metal/request_forgery_protection.rb:211:in handle_unverified_request' actionpack (5.2.4.2) lib/action_controller/metal/request_forgery_protection.rb:243:in handle_unverified_request’
devise (4.7.1) lib/devise/controllers/helpers.rb:255:in handle_unverified_request' actionpack (5.2.4.2) lib/action_controller/metal/request_forgery_protection.rb:238:in verify_authenticity_token’
activesupport (5.2.4.2) lib/active_support/callbacks.rb:426:in block in make_lambda' activesupport (5.2.4.2) lib/active_support/callbacks.rb:198:in block (2 levels) in halting’
actionpack (5.2.4.2) lib/abstract_controller/callbacks.rb:34:in block (2 levels) in <module:Callbacks>' activesupport (5.2.4.2) lib/active_support/callbacks.rb:199:in block in halting’
activesupport (5.2.4.2) lib/active_support/callbacks.rb:513:in block in invoke_before' activesupport (5.2.4.2) lib/active_support/callbacks.rb:513:in each’
activesupport (5.2.4.2) lib/active_support/callbacks.rb:513:in invoke_before' activesupport (5.2.4.2) lib/active_support/callbacks.rb:107:in block in run_callbacks’
activesupport (5.2.4.2) lib/active_support/callbacks.rb:136:in run_callbacks' actionpack (5.2.4.2) lib/abstract_controller/callbacks.rb:41:in process_action’
actionpack (5.2.4.2) lib/action_controller/metal/rescue.rb:22:in process_action' actionpack (5.2.4.2) lib/action_controller/metal/instrumentation.rb:34:in block in process_action’
activesupport (5.2.4.2) lib/active_support/notifications.rb:168:in block in instrument' activesupport (5.2.4.2) lib/active_support/notifications/instrumenter.rb:23:in instrument’
activesupport (5.2.4.2) lib/active_support/notifications.rb:168:in instrument' actionpack (5.2.4.2) lib/action_controller/metal/instrumentation.rb:32:in process_action’
actionpack (5.2.4.2) lib/action_controller/metal/params_wrapper.rb:256:in process_action' activerecord (5.2.4.2) lib/active_record/railties/controller_runtime.rb:24:in process_action’
actionpack (5.2.4.2) lib/abstract_controller/base.rb:134:in process' actionview (5.2.4.2) lib/action_view/rendering.rb:32:in process’
actionpack (5.2.4.2) lib/action_controller/metal.rb:191:in dispatch' actionpack (5.2.4.2) lib/action_controller/metal.rb:252:in dispatch’
actionpack (5.2.4.2) lib/action_dispatch/routing/route_set.rb:52:in dispatch' actionpack (5.2.4.2) lib/action_dispatch/routing/route_set.rb:34:in serve’
actionpack (5.2.4.2) lib/action_dispatch/routing/mapper.rb:18:in block in <class:Constraints>' actionpack (5.2.4.2) lib/action_dispatch/routing/mapper.rb:48:in serve’
actionpack (5.2.4.2) lib/action_dispatch/journey/router.rb:52:in block in serve' actionpack (5.2.4.2) lib/action_dispatch/journey/router.rb:35:in each’
actionpack (5.2.4.2) lib/action_dispatch/journey/router.rb:35:in serve' actionpack (5.2.4.2) lib/action_dispatch/routing/route_set.rb:840:in call’
apipie-rails (0.5.17) lib/apipie/static_dispatcher.rb:66:in call' apipie-rails (0.5.17) lib/apipie/extractor/recorder.rb:137:in call’
warden (1.2.8) lib/warden/manager.rb:36:in block in call' warden (1.2.8) lib/warden/manager.rb:34:in catch’
warden (1.2.8) lib/warden/manager.rb:34:in call' rack (2.2.2) lib/rack/tempfile_reaper.rb:15:in call’
rack (2.2.2) lib/rack/etag.rb:27:in call' rack (2.2.2) lib/rack/conditional_get.rb:40:in call’
rack (2.2.2) lib/rack/head.rb:12:in call' actionpack (5.2.4.2) lib/action_dispatch/http/content_security_policy.rb:18:in call’
rack (2.2.2) lib/rack/session/abstract/id.rb:266:in context' rack (2.2.2) lib/rack/session/abstract/id.rb:260:in call’
actionpack (5.2.4.2) lib/action_dispatch/middleware/cookies.rb:670:in call' actionpack (5.2.4.2) lib/action_dispatch/middleware/callbacks.rb:28:in block in call’
activesupport (5.2.4.2) lib/active_support/callbacks.rb:98:in run_callbacks' actionpack (5.2.4.2) lib/action_dispatch/middleware/callbacks.rb:26:in call’
actionpack (5.2.4.2) lib/action_dispatch/middleware/debug_exceptions.rb:61:in call' actionpack (5.2.4.2) lib/action_dispatch/middleware/show_exceptions.rb:33:in call’
railties (5.2.4.2) lib/rails/rack/logger.rb:38:in call_app' railties (5.2.4.2) lib/rails/rack/logger.rb:26:in block in call’
activesupport (5.2.4.2) lib/active_support/tagged_logging.rb:71:in block in tagged' activesupport (5.2.4.2) lib/active_support/tagged_logging.rb:28:in tagged’
activesupport (5.2.4.2) lib/active_support/tagged_logging.rb:71:in tagged' railties (5.2.4.2) lib/rails/rack/logger.rb:26:in call’
actionpack (5.2.4.2) lib/action_dispatch/middleware/remote_ip.rb:81:in call' actionpack (5.2.4.2) lib/action_dispatch/middleware/request_id.rb:27:in call’
rack (2.2.2) lib/rack/method_override.rb:24:in call' rack (2.2.2) lib/rack/runtime.rb:22:in call’
activesupport (5.2.4.2) lib/active_support/cache/strategy/local_cache_middleware.rb:29:in call' actionpack (5.2.4.2) lib/action_dispatch/middleware/executor.rb:14:in call’
actionpack (5.2.4.2) lib/action_dispatch/middleware/static.rb:127:in call' rack (2.2.2) lib/rack/sendfile.rb:110:in call’
railties (5.2.4.2) lib/rails/engine.rb:524:in call' puma (3.12.4) lib/puma/configuration.rb:227:in call’
puma (3.12.4) lib/puma/server.rb:675:in handle_request' puma (3.12.4) lib/puma/server.rb:476:in process_client’
puma (3.12.4) lib/puma/server.rb:334:in block in run' puma (3.12.4) lib/puma/thread_pool.rb:135:in block in spawn_thread’

</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.

Merci pour toute l’aide que tu peux m’apporter.

Cédric.

1 « J'aime »

Salut,

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 ?

Peux-tu aussi regarder le détail des logs nginx ?

Bonsoir @Sylvain,

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 :

Et en version 4.2.4, qui fonctionne très bien :

On remarque qu’en 4.2.4, il y a une clef _fablab_session qui est créée dans le cookie, mais pas en 4.3.x. Est-ce-que ça pourrait venir de là ?

Merci à nouveau pour ton aide précieuse :slight_smile:

Cédric.

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 :smile: mais je pense vraiment que le problème vient de là :wink:
Tu pourrais mettre ta conf nginx ici par hasard ?

Salut Sylvain,

Merci pour ces détails ! :slight_smile:
Voici ma conf NGINX (/apps/fabmanager.conf) :

/apps/fabmanager.conf ``` upstream puma { server fabmanager:3000; }

server {
listen 80;
server_name fabmanager.fablabancenis.fr;
root /usr/src/app/public;

location ^~ /assets/ {
gzip_static on;
expires max;
add_header Cache-Control public;
}

try_files $uri/index.html $uri @puma;
location @puma {
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://puma;
}

client_max_body_size 4G;
keepalive_timeout 10;

error_page 500 502 504 /500.html;
error_page 503 @503;

Return a 503 error if the maintenance page exists.

if (-f /usr/src/app/public/maintenance.html) {
return 503;
}

location @503 {
# Serve static assets if found.
if (-f $request_filename) {
break;
}

# Set root to the shared directory.
root /usr/src/app/public/;
rewrite ^(.*)$ /maintenance.html break;

}

location /.well-known/acme-challenge {
root /etc/letsencrypt/webrootauth;
default_type « text/plain »;
}

no spam bot

if ($http_referer ~* (guardlink.org|free-share-buttons|social-buttons|buy-cheap-online.info|social-buttons.com|free-share-buttons.com|darodar.com|blackhatworth.com|hulfingtonpost.com|priceg.com|semalt.com|imas
pammer.com|iedit.ilovevitaly.com|7makemoneyonline.com|iedit.ilovevitaly.com|7makemoneyonline.com|gamersyde.com|iloveitaly.com|econom.co|semalt.com|forum.topic44637676.darodar.com|darodar.com|iskalko.ru|ilovevita
ly.ru|ilovevitaly.com|ilovevitaly.co|o-o-8-o-o.ru|o-o-6-o-o.ru|buttons-for-website.com|semalt.semalt.com|cenoval.ru|priceg.com|darodar.com|cenokos.ru|seoexperimenty.ru|gobongo.info|vodkoved.ru|adcash.com|websoci
al.me|cityadspix.com|luxup.ru|ykecwqlixx.ru|superiends.org|slftsdybbg.ru|edakgfvwql.ru|socialseet.ru|screentoolkit.com|econom.co|semalt.com|savetubevideo.com|shopping.ilovevitaly.com|iedit.ilovevitaly.com|forum.
topic52548358.darodar.com|forum.topic53813291.darodar.com|share-buttons.com|event-tracking.com|success-seo.com|free-floating-buttons.com|get-free-social-traffic.com|chinese-amezon.com|get-free-traffic-now.com|fr
ee-social-buttons.com|videos-for-your-business.com)) { return 403; }

}

</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).

Bonsoir Sylvain,

Mauvaise nouvelle. Avec une installation de zéro, j’ai exactement le même problème ! :sweat:
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 :slight_smile:

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 :smiley:

Merci beaucoup à nouveau et désolé pour le temps passé sur ce sujet !

Cédric.

Effectivement c’est bien vu ça, je vais le rajouter, merci ! :wink:

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 )

Bonsoir @Sylvain,

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) :

CONFIG NGINX FABMANAGER (fichier fabmanager.conf) :

Ajout de cette ligne

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

en lieu et place de cette ligne dont nous avons discuté dans ce thread

proxy_set_header X-Forwarded-Proto $scheme;

CONFIG NGINX REVERSE PROXY:

location / {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Host $http_host;
    proxy_pass http://127.0.0.1:8000;
}

Par rapport à la conf que j’avais initialement, j’ai rajouté ça :

    proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;
    proxy_set_header X-Forwarded-Proto $scheme;

Et BIM !

En revanche je me heurte à un nouveau problème, désolé… :blush:
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 !!! :pray:

Cédric.

1 « J'aime »

Houra !!

Ce fut une véritable épopée :slight_smile:

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.

Salut @Sylvain

A nouveau merci pour ton aide précieuse.
J’ai pu corriger le problème de connexion admin :thumbsup:

A bientôt pour de prochaines aventures :slight_smile:

Cédric.

1 « J'aime »

6 messages ont été intégrés dans un sujet existant : Connexion impossible: Unprocessable entity