Grav-plugin-admin: Fehler beim Herunterladen (Code: 0):

Erstellt am 28. Feb. 2019  ·  24Kommentare  ·  Quelle: getgrav/grav-plugin-admin

Wenn ich versuche, das Admin-Panel (im Admin-Panel) von Version 1.8.17 auf Version 1.8.19 zu aktualisieren, wird die folgende Fehlermeldung angezeigt:

Fehler beim Herunterladen (Code: 0):
https://getgrav.org/download/plugins/admin/1.8.19 Nachricht: URL im fehlerhaften / illegalen Format oder fehlende URL

Mit SSH- und GPM-Befehlen funktioniert es einwandfrei.

40616

question

Hilfreichster Kommentar

Ich habe mich auch mit diesem Problem befasst.
Ich denke, ich weiß jetzt ein bisschen mehr darüber. Ich benutze es auch auf einem Shared Hosting.

Wenn ich in die Konfiguration gehe und unter System zu Erweitert gehe, ändere die externe Abrufmethode in "fopen" und den Remote Verify Peer (SSL) in "No" (obwohl mit einem Zertifikat von LetsEncrypt ausgeführt).
Ich bin plötzlich in der Lage, die Updates wieder herunterzuladen und zu installieren.

Vielleicht funktioniert das auch für andere ..

Alle 24 Kommentare

Können Sie versuchen, in der Systemkonfiguration von Curl zu Fopen zu wechseln oder umgekehrt?

gleicher Fall hier. Außerdem kann ich kein Plugin herunterladen

Ich benutze Shared Hosting

Können Sie überprüfen, ob Ihre PHP für CLI und Webserver gleich ist?

Können Sie uns auch mitteilen, ob Sie zum ersten Mal ein Update versuchen oder ob das Problem gerade erst aufgetreten ist, Sie aber zuvor erfolgreiche Updates hatten?

Ich habe mich auch mit diesem Problem befasst.
Ich denke, ich weiß jetzt ein bisschen mehr darüber. Ich benutze es auch auf einem Shared Hosting.

Wenn ich in die Konfiguration gehe und unter System zu Erweitert gehe, ändere die externe Abrufmethode in "fopen" und den Remote Verify Peer (SSL) in "No" (obwohl mit einem Zertifikat von LetsEncrypt ausgeführt).
Ich bin plötzlich in der Lage, die Updates wieder herunterzuladen und zu installieren.

Vielleicht funktioniert das auch für andere ..

Wenn ich in die Konfiguration gehe und unter System zu Erweitert gehe, ändere die externe Abrufmethode in "fopen" und den Remote Verify Peer (SSL) in "No" (obwohl mit einem Zertifikat von LetsEncrypt ausgeführt).
Ich bin plötzlich in der Lage, die Updates wieder herunterzuladen und zu installieren.

Ich hatte das gleiche Problem. Das hat bei mir funktioniert.

Sie haben wahrscheinlich eine zu alte Version von SSL-Stammzertifikaten auf Ihrem Server. Diese können normalerweise durch Aktualisieren der Serversoftware aktualisiert werden.

PS. Dies unterscheidet sich von Ihrem eigenen Server-SSL-Zertifikat.

Sie haben wahrscheinlich eine zu alte Version von SSL-Stammzertifikaten auf Ihrem Server. Diese können normalerweise durch Aktualisieren der Serversoftware aktualisiert werden.

PS. Dies unterscheidet sich von Ihrem eigenen Server-SSL-Zertifikat.

Das hier erwähnte Problem betrifft Shared Hosting . Die einzige Möglichkeit, das SSL-Stammzertifikat zu aktualisieren, besteht darin, den Shared Hosting-Anbieter zu fragen oder zu einem anderen Anbieter zu wechseln.
Ein Benutzer kann nichts anderes gegen das Stammzertifikat eines gemeinsam genutzten Hosts tun.

Was Sie gerade gesagt haben, wirft für mich eine rote Fahne auf. Ich würde das Hosting bezüglich des Problems kontaktieren und wenn es keine Antwort gibt, an einen anderen Ort ziehen. Es macht keinen Sinn, auf einem Host zu bleiben, der die Server nicht auf dem neuesten Stand hält. :) :)

Gibt es eine Möglichkeit, diesen Fehler mithilfe von Curl über die Befehlszeile (ssh) auf dem Server neu zu erstellen? Dies würde im Umgang mit Hosting-Anbietern sehr hilfreich sein, um den Fehler anzuzeigen und ihnen die Überprüfung zu erleichtern, ob ein Root-Zertifikat-Upgrade das Problem wirklich löst.

Ja, holen Sie sich einfach die Daten aus Ihrem Browser und konvertieren Sie sie so, dass sie mit CURL kompatibel sind. Ich bin mir ziemlich sicher, dass es auch Tools dafür gibt. Die einzige Einschränkung ist, dass Sie angemeldet sein müssen + über das Nonce-Token verfügen, was bedeutet, dass die Anforderung geringfügig geändert werden muss.

Trotzdem sollte es nicht schwierig sein, nur dem Administrator einen Benutzer zu geben und die Schritte zur Reproduktion des Problems durchzugehen. Es wird wahrscheinlich weniger Zeit von allen brauchen.

Danke @mahagr , aber ich denke, es gibt ein Missverständnis. Sie sprechen über die Verwendung von Curl, um auf Grav-Administrationsseiten zuzugreifen und das Problem neu zu erstellen? Ich meine etwas anderes:

Da der Wechsel von Curl zu Fopen in der Grav-Systemkonfiguration das Problem löst, sollte ein Curl-Aufruf von Grav intern schief gehen? Diesen Aufruf möchte ich in der Befehlszeile extrahieren und neu erstellen.

Oh, ich habe es dieses Mal verstanden - die Verwendung von curl schlägt fehl und fopen löst das Problem.

Grundsätzlich wird gesagt, dass das Ändern der Einstellung Remote Verify Peer (SSL) in No das Problem behebt, was bedeutet, dass die auf dem Server installierten SSL-Zertifikate alt sind.

Ich bin auf Shared Hosting und das Problem war eine blockierte ausgehende Verbindung zu einer IP, die ich im Control Panel meines Webhosts auf die Whitelist setzen konnte.

Ich habe mich auch mit diesem Problem befasst.
Ich denke, ich weiß jetzt ein bisschen mehr darüber. Ich benutze es auch auf einem Shared Hosting.

Wenn ich in die Konfiguration gehe und unter System zu Erweitert gehe, ändere die externe Abrufmethode in "fopen" und den Remote Verify Peer (SSL) in "No" (obwohl mit einem Zertifikat von LetsEncrypt ausgeführt).
Ich bin plötzlich in der Lage, die Updates wieder herunterzuladen und zu installieren.

Vielleicht funktioniert das auch für andere.

Ich habe mit den obigen Schritten auf Version 1.6.22 aktualisiert - danke.
Hinweis: Die externe Abrufmethode in meiner Version ist die Remoteabrufmethode
Remote Fetch Method

Ich stoße selbst auf dieses Problem (Shared Hosting, aber ich bin der Administrator. Debian 9.12, Pakete sind auf dem neuesten Stand).

Das Ändern der Abrufmethode in "Öffnen" und "Remote Verify Peer" in "Nein" hilft nicht. Ich erhalte immer noch eine ungültige AJAX-Antwort.

Ich kann den Weiterleitungen manuell mit curl -v folgen und die Datei am Ende herunterladen. Also dachte ich, ich ändere die Abrufmethode in cURL, dasselbe Problem.

Ich bin auf einem selbst gehosteten CentOS 8-Server auf dieses Problem gestoßen. SELinux blockierte Netzwerkverbindungen für den httpd-Prozess.

Stellen Sie über ssh eine Verbindung zum Server her und führen Sie Folgendes aus (Sie müssen Administrator sein):
sudo sestatus -b |grep httpd_can_network_connect
Die Standardeinstellung ist "Aus".

Stellen Sie es auf "Ein".
sudo setsebool -P httpd_can_network_connect 1

Sobald dies erledigt ist, sollte das Problem behoben sein.

Gleiches Problem hier. Das System wurde auf "Öffnen" und "Remote Verify Peer (SSL)" auf "Nein" geändert. Keine Änderung, immer noch Fehler.

Shared MediaTemple Grid Hosting ..

Grav 1.7 bietet Verbesserungen (mithilfe einer Symfony-Bibliothek) beim Herunterladen von Updates. Können Sie (auf einer Testseite) versuchen, das Problem zu beheben?

Grav 1.7 bietet Verbesserungen (mithilfe einer Symfony-Bibliothek) beim Herunterladen von Updates. Können Sie (auf einer Testseite) versuchen, das Problem zu beheben?

Das Herunterladen von Updates wurde behoben, es wird jedoch weiterhin "Abrufen fehlgeschlagen" für Dinge wie "Alten Cache löschen" angezeigt ("Abrufen fehlgeschlagen": "Abrufen fehlgeschlagen:").
1 alte Cache-Ordner gelöscht ... {"status": "success", "message": null} ')

@ezchile Kannst du bitte eine neue Ausgabe dazu erstellen?

Vielen Dank, es ist einfacher, einem offenen Thema zu folgen. :) :)

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen