Grav-plugin-admin: Erreur lors de la tentative de téléchargement (code: 0):

Créé le 28 févr. 2019  ·  24Commentaires  ·  Source: getgrav/grav-plugin-admin

Lorsque j'essaie de mettre à niveau le panneau d'administration (dans le panneau d'administration), de la v1.8.17 à la v1.8.19, j'obtiens l'erreur suivante:

Erreur lors de la tentative de téléchargement (code: 0):
https://getgrav.org/download/plugins/admin/1.8.19 Message: URL utilisant un format incorrect / illégal ou une URL manquante

Avec les commandes SSH et GPM, cela fonctionne très bien.

40616

question

Commentaire le plus utile

J'ai également évoqué ce même problème.
Je pense que j'en sais maintenant un peu plus à ce sujet. L'utiliser également sur un hébergement mutualisé.

Quand je vais dans la configuration, et sous le système allez à avancé changez la méthode de récupération externe à "fopen" ET le pair de vérification à distance (SSL) à "non" (bien que fonctionnant avec un certificat de LetsEncrypt)
Je suis soudainement capable de télécharger et d'installer à nouveau les mises à jour.

Peut-être que cela fonctionne aussi pour d'autres.

Tous les 24 commentaires

Pouvez-vous essayer de passer de Curl à Fopen dans la configuration du système ou vice versa?

même cas ici. de plus, je ne peux télécharger aucun plugin

j'utilise l'hébergement mutualisé

Pouvez-vous vérifier que votre php est le même pour le cli et le serveur Web?

Pouvez-vous également nous indiquer si c'est la première fois que vous essayez une mise à jour ou si le problème vient de commencer à apparaître mais que vous avez déjà eu des mises à jour réussies?

J'ai également évoqué ce même problème.
Je pense que j'en sais maintenant un peu plus à ce sujet. L'utiliser également sur un hébergement mutualisé.

Quand je vais dans la configuration, et sous le système allez à avancé changez la méthode de récupération externe à "fopen" ET le pair de vérification à distance (SSL) à "non" (bien que fonctionnant avec un certificat de LetsEncrypt)
Je suis soudainement capable de télécharger et d'installer à nouveau les mises à jour.

Peut-être que cela fonctionne aussi pour d'autres.

Quand je vais dans la configuration, et sous le système allez à avancé changez la méthode de récupération externe à "fopen" ET le pair de vérification à distance (SSL) à "non" (bien que fonctionnant avec un certificat de LetsEncrypt)
Je suis soudainement capable de télécharger et d'installer à nouveau les mises à jour.

J'ai eu le même problème. Cela a fonctionné pour moi.

Vous avez probablement une version trop ancienne des certificats racine SSL sur votre serveur. Ceux-ci peuvent généralement être mis à jour en mettant à niveau le logiciel serveur.

PS. ceci est différent de votre propre certificat SSL de serveur.

Vous avez probablement une version trop ancienne des certificats racine SSL sur votre serveur. Ceux-ci peuvent généralement être mis à jour en mettant à niveau le logiciel serveur.

PS. ceci est différent de votre propre certificat SSL de serveur.

Le problème mentionné ici concerne l' hébergement partagé , donc, le seul moyen de mettre à niveau le certificat racine SSL est de demander au fournisseur d'hébergement partagé ou de passer à un autre fournisseur ...
Un utilisateur ne peut rien faire d'autre concernant le certificat racine d'un hôte partagé.

Ce que vous venez de dire soulève un drapeau rouge pour moi. Je contacterais l'hébergement à propos du problème et s'il n'y a pas de réponse, je déménagerais ailleurs. Il ne sert à rien de rester dans un hébergeur qui ne tient pas les serveurs à jour. :)

Existe-t-il un moyen de recréer cette erreur en utilisant curl à partir de la ligne de commande (ssh) sur le serveur? Cela aiderait beaucoup, lorsqu'ils traitent avec les fournisseurs d'hébergement, à montrer l'erreur et à leur permettre de vérifier plus facilement qu'une mise à niveau du certificat racine résout vraiment le problème.

Oui, récupérez simplement les données de votre navigateur et convertissez-les pour qu'elles soient compatibles avec CURL - je suis presque sûr qu'il existe également des outils pour cela. La seule mise en garde est que vous devez être connecté + avoir le jeton nonce, ce qui signifie que la demande doit être légèrement modifiée.

Cela dit, il ne devrait pas être difficile de donner simplement un utilisateur administrateur et de suivre les étapes pour reproduire le problème. Cela prendra probablement moins de temps à tout le monde.

Merci @mahagr , mais je pense qu'il y a un malentendu. Vous parlez d'utiliser curl pour accéder aux pages d'administration de grav pour recréer le problème? Je veux dire autre chose:

Puisque le passage de curl à fopen dans la configuration du système grav le résout, il devrait y avoir un appel curl de grav qui ne va pas en interne? C'est cet appel que je veux extraire et recréer sur la ligne de commande.

Oh, je l'ai eu cette fois - l'utilisation de curl fait échouer et fopen résout le problème.

Fondamentalement, les gens disent que changer le paramètre Remote Verify Peer (SSL) en No résout le problème, ce qui signifie que les certificats SSL installés sur le serveur sont anciens.

Je suis sur un hébergement partagé et le problème était une connexion sortante bloquée à une adresse IP que je pouvais mettre sur liste blanche dans le panneau de configuration de mon hébergeur,

J'ai également évoqué ce même problème.
Je pense que j'en sais maintenant un peu plus à ce sujet. L'utiliser également sur un hébergement mutualisé.

Quand je vais dans la configuration, et sous le système allez à avancé changez la méthode de récupération externe à "fopen" ET le pair de vérification à distance (SSL) à "non" (bien que fonctionnant avec un certificat de LetsEncrypt)
Je suis soudainement capable de télécharger et d'installer à nouveau les mises à jour.

Peut-être que cela fonctionne aussi pour d'autres.

J'ai mis à jour la version 1.6.22 en suivant les étapes ci-dessus - merci.
Remarque: la méthode de récupération externe sur ma version est la méthode de récupération à distance
Remote Fetch Method

Je rencontre moi-même ce problème (hébergement partagé, mais je suis l'administrateur. Debian 9.12, les paquets sont à jour).

Changer la méthode de récupération pour fopen et Remote Verify Peer sur No n'aide pas. Je reçois toujours une réponse AJAX invalide.

Je peux suivre manuellement les redirections avec curl -v et télécharger le fichier à la fin. J'ai donc pensé changer la méthode Fetch en cURL, même problème.

J'ai rencontré ce problème sur un serveur CentOS 8 auto-hébergé. SELinux bloquait les connexions réseau pour le processus httpd.

Connectez-vous au serveur par ssh et exécutez ce qui suit (vous devez être administrateur):
sudo sestatus -b |grep httpd_can_network_connect
La valeur par défaut est "off".

Réglez-le sur "on"
sudo setsebool -P httpd_can_network_connect 1

Une fois que cela est fait, le problème doit être résolu.

Même problème ici. Changement du système en fopen et «Remote Verify Peer (SSL)» en no .. Pas de changement, toujours des erreurs.

Hébergement Shared MediaTemple Grid.

Grav 1.7 a des améliorations (en utilisant une bibliothèque Symfony) sur le téléchargement des mises à jour. Pouvez-vous essayer (sur un site de test) s'ils résolvent le problème?

Grav 1.7 a des améliorations (en utilisant une bibliothèque Symfony) sur le téléchargement des mises à jour. Pouvez-vous essayer (sur un site de test) s'ils résolvent le problème?

Le téléchargement des mises à jour a été corrigé, mais affiche toujours `` Échec de la récupération '' pour des choses comme `` Purger l'ancien cache '' (`` Échec de la récupération:
Purge d'un ancien dossier de cache ... {"status": "success", "message": null} ')

@ezchile Pouvez-vous s'il vous plaît créer un nouveau numéro à ce sujet?

Merci, il est plus facile de suivre un problème ouvert. :)

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

Genenenenaam picture Genenenenaam  ·  5Commentaires

orasik picture orasik  ·  6Commentaires

jundiya picture jundiya  ·  4Commentaires

ritchiedalto picture ritchiedalto  ·  6Commentaires

ghost picture ghost  ·  6Commentaires