Plots2: Échec du téléchargement de l'image

Référence également #9442 pour un problème mineur.

merci @waridrox :+1:

En essayant de déboguer davantage le problème, l'erreur que j'ai eue lors du téléchargement d'une image à partir du stockage de fichiers local était
Paperclip::Errors::CommandNotFoundError: Could not run the 'identify' command. Please install ImageMagick.
sous environnement de développement local. Je crois que c'est une nouvelle dépendance pour paperclip gem qui traite des téléchargements de fichiers.

Après avoir installé imagemagick avec la commande sudo apt-get install imagemagick ou brew install imagemagick , j'ai ajouté ces 2 lignes de code dans le fichier development.rb .

Paperclip.options[:image_magick_path] = "/opt/ImageMagick/bin"
Paperclip.options[:command_path] = "/opt/ImageMagick/bin"

Après cela, j'ai simplement redémarré le serveur et le téléchargement du fichier était à nouveau fonctionnel avec des types de fichiers tels que jpeg , png et gif . Voici un aperçu de la même chose -

https://user-images.githubusercontent.com/58583793/113514702-c308e700-958d-11eb-8e12-59c7a9648b24.mp4

À partir de _ce fil_ sur stackoverflow, nous devons également ajouter ces 2 lignes dans production.rb pour refléter les changements dans l'application de production.

Également en raison du paramètre facultatif pour installer image-magick dans https://github.com/publiclab/plots2/blob/main/doc/PREREQUISITES.md#image -libraries-facultatif, ce comportement a été observé en premier lieu.

Merci @waridrox , j'ai retiré vos modifications et

Oh, vraiment désolé pour ça, veuillez alors inverser la traction. Est-ce que ça marche en local ? Peut-être qu'essayer d'abord sudo apt-get update puis sudo apt-get install imagemagick peut aider...

Salut à tous, localement, il est logique que ce soit un imagemagick mais (ou l'absence d'imagemagick) mais sur stable, il devrait être installé. Je me demande si c'est un bug distinct sur stable? Nous devrions recouper Sentry.io. Cess avez-vous accès?

Merci d'avoir trouvé et documenté cela !!

Je ne vois pas d'erreurs de sentinelle sur le téléchargement d'images, sauf en ce qui concerne les photos de profil (ce qui est souvent le cas en raison du spam et des attaques).

Quel est le chemin de l'erreur ? C'est une erreur 500 ?

Désolé je veux dire /récentes/ erreurs

@waridrox cela n'a pas fonctionné pour moi localement peut-être que j'ai la mauvaise version .. @jywarren c'était plus une erreur 302 de mon côté

Aha, erreur 302 en effet... 🕵️

Je vais voir pourquoi cela peut être le cas. Merci!

Je vais essayer de l'exécuter dans GitPod pour voir si je peux reproduire le 302 ...

OK, j'ai un journal de GitPod !

Started POST "/images" for 10.4.6.182 at 2021-04-13 18:36:40 +0000
Cannot render console from 10.4.0.249! Allowed networks: 127.0.0.1, ::1, 127.0.0.0/127.255.255.255
Processing by ImagesController#create as JSON
  Parameters: {"nid"=>"null", "image"=>{"photo"=>#<ActionDispatch::Http::UploadedFile:0x00007f444ce23c30 @tempfile=#<Tempfile:/tmp/RackMultipart20210413-4879-sla487.jpg>, @original_filename="11aa-love-ryan2-720.jpg", @content_type="image/jpeg", @headers="Content-Disposition: form-data; name=\"image[photo]\"; filename=\"11aa-love-ryan2-720.jpg\"\r\nContent-Type: image/jpeg\r\n">}}
Can't verify CSRF token authenticity.
Redirected to https://3000-aquamarine-bass-qsunlo8p.ws-us03.gitpod.io/login?return_to=/images
Filter chain halted as :require_user rendered or redirected
Completed 302 Found in 2ms (ActiveRecord: 0.0ms)


Started GET "/login?return_to=/images" for 10.4.6.182 at 2021-04-13 18:36:40 +0000
Cannot render console from 10.4.0.249! Allowed networks: 127.0.0.1, ::1, 127.0.0.0/127.255.255.255
Processing by UserSessionsController#new as JSON
  Parameters: {"return_to"=>"/images"}
  User Load (0.5ms)  SELECT  `rusers`.* FROM `rusers` WHERE `rusers`.`id` = 1 LIMIT 1
   (0.2ms)  BEGIN
  User Update (0.5ms)  UPDATE `rusers` SET `last_request_at` = '2021-04-13 18:36:40', `updated_at` = '2021-04-13 18:36:40' WHERE `rusers`.`id` = 1
   (28.6ms)  COMMIT
Redirected to https://localhost/home?return_to=%2Flogin
Filter chain halted as :require_no_user rendered or redirected
Completed 302 Found in 35ms (ActiveRecord: 29.7ms)

OK, alors pourquoi sommes-nous redirigés pour nous connecter... à la recherche...

On dirait que le jeton CSRF ne fonctionne pas... voyons voir...

https://github.com/publiclab/plots2/blob/bd7b2e26c1edbd85a9754d8b25bc27950fd99770/app/views/editor/rich.html.erb#L344 -L347

nous le passons ici.

$('meta[name="csrf-token"]').attr('content') récupère correctement le jeton, donc ce n'est pas ça...

En notant que dans GitPod, le principal téléchargeur d'images fonctionne. Il utilise le même contrôleur, le problème semble donc probablement provenir du code du module de texte enrichi de l'éditeur lui-même :

Started POST "/images" for 10.4.0.248 at 2021-04-13 18:47:45 +0000
Cannot render console from 10.4.6.181! Allowed networks: 127.0.0.1, ::1, 127.0.0.0/127.255.255.255
Processing by ImagesController#create as JSON
  Parameters: {"authenticity_token"=>"5Z5plBlzFXbu2qCKPTDZYa54DWaNn556hs9FzyvH2U8NDMabePLVh1RlBuhkRR+Ej+kgI/hLIAm9LcdrEZv4lg==", "uid"=>"1", "image"=>{"photo"=>#<ActionDispatch::Http::UploadedFile:0x000055644bef1898 @tempfile=#<Tempfile:/tmp/RackMultipart20210413-5664-bsht8f.jpg>, @original_filename="11aa-love-ryan2-720.jpg", @content_type="image/jpeg", @headers="Content-Disposition: form-data; name=\"image[photo]\"; filename=\"11aa-love-ryan2-720.jpg\"\r\nContent-Type: image/jpeg\r\n">}}

Et en fait, le principal téléchargeur d'images utilise également le jeton dans sa requête :

https://github.com/publiclab/PublicLab.Editor/blob/59e5bf6fd1ac2b6f9108e522baa7cdab36e0bb64/src/modules/PublicLab.MainImageModule.js#L94

Il le récupère correctement avec :

editor.options.mainImageModule.token
"5Z5plBlzFXbu2qCKPTDZYa54DWaNn556hs9FzyvH2U8NDMabePLVh1RlBuhkRR+Ej+kgI/hLIAm9LcdrEZv4lg=="

Confirmé. Le téléchargement de l'image principale a cet ensemble de paramètres dans la demande de formulaire :

authenticity_token: 5Z5plBlzFXbu2qCKPTDZYa54DWaNn556hs9FzyvH2U8NDMabePLVh1RlBuhkRR+Ej+kgI/hLIAm9LcdrEZv4lg==
uid: 1
image[photo]: (binary)

Alors que le téléchargement d'image en ligne n'a que ces éléments :

nid: null
image[photo]: (binary)

vérifier les modifications récentes apportées à cette section de code, ainsi que les options du module elles-mêmes pour s'assurer qu'elles sont correctement stockées/transmises par le constructeur.

Wow, bug profond. Poursuivre via https://github.com/jywarren/woofmark/pull/2 vers la bibliothèque woofmark : https://github.com/bevacqua/woofmark/pull/44

Il est présent dans notre succursale de woofmark :

https://github.com/jywarren/woofmark/blob/plots2/src/prompts/prompt.js#L133

Je crois que ce PR d'il y a 28 jours peut être lié. le dernier changement apporté à la branche de woofmark nous utilisons a eu lieu en septembre 2020.

https://github.com/jywarren/woofmark/pull/76/files

Je ne vois rien dans le code de woofmark -- 2 routes maintenant :

1. traçage du paramètre upload.xhrOptions via Woofmark et confirmation qu'il l'a correctement obtenu
2. voir si le module xhr npm a changé

https://www.npmjs.com/package/xhr a publié 2.6 il y a 5 mois mais est à 2.2.1 depuis de nombreux mois dans nos projets. confirmé dans package-lock.json

OK, donc le upload.xhrOptions beforeSend transforme en woofmark , comme testé dans la console JS.

Génère-t-il réellement l'en-tête supplémentaire ?

xhrOptions: { 
        beforeSend: function(xhr) { xhr.setRequestHeader('X-CSRF-Token', $('meta[name="csrf-token"]').attr('content')) }
      },

Mon Dieu, je ne sais pas quand cela a cessé de fonctionner, mais je pense que nous pourrions simplement ajouter un autre paramètre formData et le faire de cette façon ??? Mais vous ne savez pas si cela va passer avec les autres, ou si la bibliothèque xhr l'ignorera ?

Notant que cela se serait produit soit le 5 novembre 2020 dans https://github.com/publiclab/PublicLab.Editor/releases/tag/v3.0 ou il y a 28 jours dans https://github.com/publiclab/plots2/pull/ 9323

D'après cette ligne, je pense que formData devrait être transmis normalement :

https://github.com/bevacqua/woofmark/pull/44/files#diff -b70752c6e4fb751c6aa381f57afac66c25cc2d401b141b03e1751d81e60efcd2R216

va essayer dans GitPod :

      formData: {nid: null, authenticity_token: _module.options.token},

... QUI L'A FAIT :

Corrigera dans https://github.com/publiclab/PublicLab.Editor/pull/712 , version 3.0.3, et ajoutera également le jeton supplémentaire formData dans https://github.com/publiclab/plots2 /pull/9504.

Ouf!

Fait et confirmé en écurie !

@publiclab-mimi a rapporté aujourd'hui que

Sur l'éditeur de notes de recherche, je n'ai pas pu télécharger de JPEG, PDF ou PNG.
Sur Google Chrome et Safari, les options de glisser-déposer et de navigation

@ebarry , je pense que la version actuelle n'a toujours pas les modifications ci-dessus en raison du temps de mémoire tampon requis pour appliquer les modifications à la version en direct. C'est parce que le téléchargement d'images/fichiers fonctionne sur la version stable et la version héritée.

Le nouveau code a été mis en ligne hier soir ! En regardant, je vois une nouvelle erreur - une erreur 500 :

à commencer par celui-ci, qui est le même 302 que Cess a trouvé :

Puis redirigé vers cette nouvelle erreur 500 :

qui est en fait sur une connexion réussie, je crois, mais c'est bizarre parce que je suis déjà connecté ?

Sentry l'a enregistré ici, je pense, mais je ne sais pas si l'erreur se produit avant ou après la tentative de connexion.

https://sentry.io/share/issue/13e10e65210c4ceb9860ec687482d9b7/

```
ActionView::MissingTemplate
Modèle home/home manquant avec {:locale=>[:en], :formats=>[:json], :variants=>[], :handlers=>[:raw, :erb, :html, :builder, : ruby, :café, :jbuilder]}. Recherche dans :

• "/app/app/vues"
• "/usr/local/bundle/gems/grape-swagger-ui-2.2.8/app/views"
• "/usr/local/bundle/gems/grape-swagger-rails-0.3.1/app/views"
• ```

Hein, j'ai du mal à retracer cela, alors je vais essayer de reproduire à nouveau dans GitPod ???

OK, @icarito et moi avons pu résoudre un problème de mise à jour de fil pour extraire le vrai code de l'éditeur 3.0.3 , l'avoir confirmé, puis corrigé un autre problème de configuration nginx lié à SSL et c'est maintenant travailler sur le site en direct. Merci tout le monde!

: puis :: puis :: puis:

impressionnant!!! Merci