Nach der Installation von Discourse mit “Docker version 20.10.5, build 55c4c8” auf CentOS 8 läuft die Seite, aber DELETE-Aufrufe an /draft.json timen immer aus.
Apache läuft und ich habe es sowohl mit einem Apache-Reverse-Proxy als auch mit HAProxy versucht; das Verhalten ist identisch.
Ich weiß nicht, ob dies damit zusammenhängt, aber ich finde viele dieser Fehler in unicorn.stdout.log:
==> ./shared/standalone/log/rails/unicorn.stdout.log <==
2021-03-18T10:02:25.138Z pid=108 tid=ocs ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Starting up 1 supervised sidekiqs
Loading Sidekiq in process id 119
2021-03-18T10:40:09.682Z pid=119 tid=orn ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
2021-03-18T10:40:09.684Z pid=119 tid=ohf ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
2021-03-18T10:40:09.685Z pid=119 tid=owv ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
2021-03-18T10:40:09.683Z pid=119 tid=oob ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
2021-03-18T10:40:09.683Z pid=119 tid=omr ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Starting up 1 supervised sidekiqs
Loading Sidekiq in process id 121
Ich kann weiterhin keine Beiträge, Einladungen und gelöschte Beitragsänderungen löschen.
Es scheint ein Problem bei allen Aufrufen mit der HTTP-DELETE-Methode zu sein. Sollte Discourse nicht POST anstelle von DELETE verwenden? Das erinnert an How can Discourse make POST instead of DELETE for "smart" CDN?, aber ich verwende keinen CDN, sondern einen normalen virtuellen Server mit CentOS und einer Docker-Installation gemäß den Anweisungen auf der Discourse-Website.
Dies ist production.log. Ich sehe keine DELETE-Anfrage, aber alles andere wird registriert (Beitrag öffnen, ändern, speichern usw.):
Completed 200 OK in 81ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 14861)
Started GET "/composer_messages?composer_action=edit&topic_id=10&post_id=13" for 176.243.226.205 at 2021-03-20 15:51:09 +0100
Processing by ComposerMessagesController#index as JSON
Parameters: {"composer_action"=>"edit", "topic_id"=>"10", "post_id"=>"13"}
Completed 200 OK in 1191ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 16940)
Started POST "/presence/publish" for 176.243.226.205 at 2021-03-20 15:51:14 +0100
Processing by Presence::PresencesController#handle_message as */*
Parameters: {"state"=>"editing", "topic_id"=>"10", "post_id"=>"13"}
Completed 200 OK in 9ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 3192)
Started PUT "/t/e-previsto-un-ritorno-di-freddo-nutro/10" for 176.243.226.205 at 2021-03-20 15:51:17 +0100
Processing by TopicsController#update as */*
Parameters: {"title"=>"E' previsto un ritorno di freddo, nutro?", "category_id"=>1, "slug"=>"e-previsto-un-ritorno-di-freddo-nutro", "topic_id"=>"10", "topic"=>{"title"=>"E' previsto un ritorno di freddo, nutro?", "category_id"=>1}}
Completed 200 OK in 19ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 5149)
Started POST "/presence/publish" for 176.243.226.205 at 2021-03-20 15:51:17 +0100
Processing by Presence::PresencesController#handle_message as */*
Parameters: {"state"=>"closed", "topic_id"=>"10"}
Completed 200 OK in 10ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 3159)
Started PUT "/posts/13" for 176.243.226.205 at 2021-03-20 15:51:17 +0100
Processing by PostsController#update as */*
Parameters: {"post"=>{"edit_reason"=>"", "cooked"=>"<p>post di test per vedere. ssss</p>", "raw"=>"post di test per vedere. ssss", "topic_id"=>"10", "raw_old"=>""}, "id"=>"13"}
Completed 200 OK in 3296ms (Views: 0.1ms | ActiveRecord: 0.0ms | Allocations: 86638)
Started GET "/t/10.json" for 176.243.226.205 at 2021-03-20 15:51:20 +0100
Processing by TopicsController#show as JSON
Parameters: {"id"=>"10"}
Completed 200 OK in 143ms (Views: 0.1ms | ActiveRecord: 0.0ms | Allocations: 52707)
Started GET "/draft.json?draft_key=topic_10" for 176.243.226.205 at 2021-03-20 15:51:27 +0100
Processing by DraftController#show as JSON
Parameters: {"draft_key"=>"topic_10"}
Completed 200 OK in 38ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 4317)
Started GET "/posts/13" for 176.243.226.205 at 2021-03-20 15:51:27 +0100
Processing by PostsController#show as JSON
Parameters: {"id"=>"13"}
Completed 200 OK in 16ms (Views: 0.1ms | ActiveRecord: 0.0ms | Allocations: 5026)
Started POST "/presence/publish" for 176.243.226.205 at 2021-03-20 15:51:29 +0100
Processing by Presence::PresencesController#handle_message as */*
Parameters: {"state"=>"editing", "topic_id"=>"10", "post_id"=>"13"}
Completed 200 OK in 20ms (Views: 0.3ms | ActiveRecord: 0.0ms | Allocations: 3304)
Started GET "/posts/13" for 176.243.226.205 at 2021-03-20 15:51:38 +0100
Processing by PostsController#show as JSON
Parameters: {"id"=>"13"}
Completed 200 OK in 121ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 56890)
[quote=“Andrea_Giovacchini, Beitrag:6, Thema:183647”]
Wenn diese DELETE-Anfragen HAProxy erreichen, sollten sie auch die Software im Docker-Container erreichen. Kann etwas dort für das Problem „verantwortlich
Wir nutzen die DELETE-/PUT-Verben in der gesamten Anwendung für jede einzelne Installation und haben keine Probleme festgestellt. Daher vermute ich, dass es sich um ein Problem handelt, das spezifisch für Ihre Installation ist.
Eine eher unwahrscheinliche Vermutung, aber haben Sie eine WAF (Web Application Firewall) oder ähnliches, das diese Domain absichert, @Andrea_Giovacchini?
Ah, verstehe. Da das Problem bei einer Neuinstallation nicht reproduzierbar ist, schlage ich vor, dieses Thema zu schließen. Falls das Problem erneut auftritt, eröffne bitte ein neues Thema mit den Schritten zur Reproduktion.
Der Curl-Befehl liefert einen schlechten CSRF-Token, erscheint sofort im internen Nginx-Log von Discourse, aber das Löschen über die Oberfläche funktioniert nicht. Im Log taucht es mit einer Verzögerung von etwa 35 Sekunden auf, wie in dem Video, das ich gesendet habe.
Wenn ich in der app.yml den Hostnamen als discourse.apicolturaitalianafb.it:8880 setze, neu erstelle und zu http://discourse.apicolturaitalianafb.it:8880 gehe, funktioniert es normal. Aber ich kann das nicht so nutzen.
Da ich Apache mit einer produktiven Website laufen habe, habe ich versucht, es gemäß der Dokumentation auf dieser Website hinter einen HAProxy zu stellen. Dabei funktionieren die Löschvorgänge in Discourse nicht mehr, aber dein Curl-Befehl funktioniert. Ich habe auch einen Apache-Reverse-Proxy ausprobiert: Curl funktioniert, aber das Löschen in Discourse nicht. Ich habe zudem versucht, Discourse über einen Unix-Socket laufen zu lassen und diesen per Reverse-Proxy weiterzuleiten, aber das Problem bleibt gleich.
Für mich ist es ein klares Indiz, dass das Reverse-Proxying die Löschvorgänge nicht blockiert, sondern dass JavaScript in Discourse aus irgendeinem Grund die korrekten HTML-Löschungen nicht mehr ausführt.
Ist deine frische Installation, die du getestet hast, direkt exponiert?
.