Plots2: Bild-Upload fehlgeschlagen

Verweise auch auf #9442 für ein kleineres Problem.

danke @waridrox :+1:

Beim Versuch, das Problem weiter zu debuggen, war der Fehler, den ich beim Hochladen eines Bildes aus dem lokalen Dateispeicher erhielt:
Paperclip::Errors::CommandNotFoundError: Could not run the 'identify' command. Please install ImageMagick.
unter lokaler Entwicklungsumgebung. Dies ist meiner Meinung nach eine neue Abhängigkeit von paperclip gem, die sich mit Datei-Uploads befasst.

Nachdem ich imagemagick mit dem Befehl sudo apt-get install imagemagick oder brew install imagemagick installiert hatte, fügte ich diese 2 Codezeilen in die Datei development.rb .

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

Danach habe ich einfach den Server neu gestartet und der Dateiupload funktionierte wieder mit Dateitypen wie jpeg , png und gif . Hier ist ein Einblick in dasselbe -

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

Ab _diesem Thread_ bei Stackoverflow müssen wir diese beiden Zeilen auch in production.rb hinzufügen, um die Änderungen in der Produktions-App widerzuspiegeln.

Auch aufgrund des optionalen Parameters zur Installation von image-magick in https://github.com/publiclab/plots2/blob/main/doc/PREREQUISITES.md#image -libraries-optional wurde dieses Verhalten in erster Linie beobachtet.

Danke @waridrox , ich habe Ihre Änderungen gezogen und

Oh, das tut mir wirklich leid, dann kehre bitte den Zug zurück. Funktioniert es aber lokal? Vielleicht hilft es, zuerst sudo apt-get update und dann sudo apt-get install imagemagick auszuprobieren...

Hallo zusammen, lokal macht es einen Sinn, dass es ein Imagemagick ist, aber (oder kein Imagemagick) aber auf Stable installiert werden sollte. Ich frage mich, ob es ein eindeutiger Bug auf Stable ist? Wir sollten Sentry.io überprüfen. Hast du Zugriff?

Danke, dass du das gefunden und dokumentiert hast!!

Ich sehe keine Sentry-Fehler beim Hochladen von Bildern, außer in Bezug auf Profilbilder (was aufgrund von Spam und Angriffen oft der Fall ist).

Was ist der Pfad für den Fehler? Es ist ein 500er Fehler?

Entschuldigung, ich meine /letzte/ Fehler

@waridrox es hat bei mir lokal nicht funktioniert vielleicht habe ich die falsche Version.. @jywarren es war eher ein 302 Fehler auf meiner Seite

Aha, 302 Fehler in der Tat... 🕵️

Ich schau mal warum das so sein kann. Vielen Dank!

Ich werde versuchen, es in GitPod auszuführen, um zu sehen, ob ich das 302 reproduzieren kann ...

OK, habe ein Protokoll von 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, also warum werden wir zum Einloggen weitergeleitet... suchen...

Sieht so aus, als ob das CSRF-Token nicht funktioniert ... mal sehen ...

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

wir geben es hier ein.

$('meta[name="csrf-token"]').attr('content') ruft das Token korrekt ab, das ist es also nicht...

Beachten Sie, dass in GitPod der Hauptbild-Uploader funktioniert. Es verwendet den gleichen Controller, daher scheint das Problem wahrscheinlich im Rich-Text-Modul-Code des Editors selbst zu liegen:

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">}}

Und tatsächlich verwendet auch der Hauptbild-Uploader das Token in seiner Anfrage:

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

Es holt es korrekt mit:

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

Bestätigt. Der Hauptbild-Upload hat diesen Parametersatz in der Formularanfrage:

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

Während der Inline-Bild-Upload nur diese hat:

nid: null
image[photo]: (binary)

Überprüfung der letzten Änderungen an diesem Codeabschnitt sowie der Moduloptionen selbst, um sicherzustellen, dass er ordnungsgemäß vom Konstruktor gespeichert/übergeben wird.

Wow, tiefer Fehler. Zurück durch https://github.com/jywarren/woofmark/pull/2 zur woofmark Bibliothek: https://github.com/bevacqua/woofmark/pull/44

Es ist in unserer Filiale von woofmark :

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

Ich glaube, dass diese PR von vor 28 Tagen verwandt sein könnte. die letzte Änderung des von uns verwendeten Zweigs von woofmark erfolgte im September 2020.

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

Ich sehe nichts im Code in woofmark -- 2 Routen jetzt:

1. den upload.xhrOptions Parameter durch Woofmark verfolgen und bestätigen, dass er richtig verstanden wurde
2. sehen, ob sich das xhr npm-Modul geändert hat

https://www.npmjs.com/package/xhr hat vor 5 Monaten 2.6 veröffentlicht, ist aber seit vielen Monaten in unseren Projekten bei 2.2.1. bestätigt in package-lock.json

OK, also der Parameter upload.xhrOptions beforeSend schafft es in woofmark , wie in der JS-Konsole getestet.

Generiert es tatsächlich den zusätzlichen Header?

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

Meine Güte, ich weiß nicht, wann das aufgehört hat zu funktionieren, aber ich denke, wir könnten möglicherweise einfach einen weiteren formData Parameter hinzufügen und es so machen??? Aber nicht sicher, ob es mit den anderen übersehen wird oder ob die xhr-Bibliothek es ignoriert?

Dies wäre entweder am 5. November 2020 in https://github.com/publiclab/PublicLab.Editor/releases/tag/v3.0 oder vor 28 Tagen in https://github.com/publiclab/plots2/pull/ passiert.

Laut dieser Zeile glaube ich, dass formData normal übergeben werden sollte:

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

werde es in GitPod versuchen:

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

... DAS war's:

Wird in https://github.com/publiclab/PublicLab.Editor/pull/712 , Version 3.0.3 behoben und auch das zusätzliche formData Token in https://github.com/publiclab/plots2 hinzugefügt

Wütend!

Fertig und im Stall bestätigt!

@publiclab-mimi hat heute berichtet, dass

Im Editor für Forschungsnotizen konnte ich kein JPEG, PDF oder PNG hochladen.
In Google Chrome und Safari sowohl Drag-and-Drop- als auch Browse-Optionen

@ebarry , ich denke, die aktuelle Version enthält die oben genannten Änderungen immer noch nicht, da die Pufferzeit erforderlich ist, um die Änderungen in die Live-Version zu übertragen. Das liegt daran, dass das Hochladen von Bildern / Dateien auf der stabilen Version und der Legacy-Version funktioniert.

Der neue Code ging gestern Abend live! Wenn ich nachschaue, sehe ich einen neuen Fehler - einen 500-Fehler:

beginnend mit diesem, das die gleiche 302 ist, die Cess gefunden hat:

Dann zu diesem neuen 500-Fehler weitergeleitet:

Was ist eigentlich bei einem erfolgreichen Login, glaube ich, aber es ist seltsam, weil ich bereits eingeloggt bin?

Sentry hat es hier protokolliert, denke ich, aber ich bin mir nicht sicher, ob der Fehler vor oder nach dem Anmeldeversuch auftritt.

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

```
ActionView::MissingTemplate
Fehlende Vorlage home/home mit {:locale=>[:en], :formats=>[:json], :variants=>[], :handlers=>[:raw, :erb, :html, :builder, : rubin, :kaffee, :jbuilder]}. Gesucht in:

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

Huh, ich habe Probleme, dies zu verfolgen, also werde ich es erneut in GitPod versuchen?

OK, @icarito und ich konnten ein Problem mit der 3.0.3 Editor-Code einzuziehen , es zu bestätigen und dann ein weiteres nginx Konfigurationsproblem im Zusammenhang mit SSL zu beheben und es ist jetzt an der Live-Site arbeiten. Danke, alle!

: dann:: dann:: dann:

genial!!! Danke