pitch78

Que donne le log "Réponse brute de l'api à https://api.1fichier.com/v1/file/info.cgi"?

👌🏻

En gros, l'url appelée pour faire la vérification est très (beaucoup trop) sensible et peut déclencher un status de flood (trop de rêquetes, donc suspect) sur le compte après 2/3 appels, voir même un seul appel... Et cela peut aller jusqu'au blocage (temporaire) de l'IP si l'on continue. A noter qu'avant c'est le site de 1fichier lui-même qui était analysé pour déterminer le type de compte, cette fonction était donc utile pour confirmer que le status free / premium était bien identifié. Maintenant que le fichier host passe par l'API de 1fichier, cette vérification n'a plus de sens / intérêt car les membres utilisant cette version sont forcément premium, sinon ils n'auraient pas accès à l'API. Après, c'est en place car je suppose que c'est une contrainte pour le fichier host, que d'avoir cette fonction. Les urls de téléchargement se comportent elles "normalement" et devrait fonctionner à condition que le compte ne soit pas bloqué (temporairement) par notamment des appels à l'url de vérification. En gros si vous avez votre clé API, mettez la bien dans le champ password et ne faites pas de vérification. Et si cela ne fonctionne pas alors activez les logs.

arf, c'est vraiment plus embêtant là du coup 😩 j'espérai vraiment une erreur franche...

Ok, bon c'est pas grave. Le truc c'est que pour l'instant le script fait tout ce qui est nécessaire quand tout va bien et honnêtement, vue la simplicité (c'est un compliment) je pensais pas qu'il y ait vraiment besoin de plus. @Faucon Noir, S'il n'y a pas de log car le script n'écrit rien, pas de texte, de logs,... Le plus simple serait soit d'éxécuter une requête depuis postman ou un équivalent, ou si vous savez utiliser la ligne de commande. un curl ou un wget, genre: curl --location 'https://api.1fichier.com/v1/file/info.cgi' --header 'Content-Type: application/json' --header 'Authorization: Bearer votre_token_ici' --data '{ "url": "url_1fichier__de_test_ici"}' en remplaçant évidemment votre_token_ici par votre clé API 1fichier et url_1fichier__de_test_ici par une vrai url de type https://1fichier.com/?XYZ Attention, pour ces requêtes faites "main" pensez bien à enlever la partie affiliation: &af=1324567 sinon, cela ne fonctionne pas. et vous aurez une réponse du genre: { "message": "Resource not found #520", "status": "KO" } Dans le script, il le fait pour vous. Vous pouvez aussi essayé l'autre url "utile" et mettre https://api.1fichier.com/v1/download/get_token.cgi à la place de https://api.1fichier.com/v1/file/info.cgi dans la commande ci-dessous le résultat donnera alors peut-être plus de précision sur la nature de vos erreurs 🤞🏻

@baobab379 et @Holborn A, avez-vous essayé directement de lancer un téléchargement, sans faire la vérification de compte? Avec la version 4.0.X, la vérification de compte ne sert plus vraiment utile (peut-être si / quand le cdn sera remis, je ne sais pas) Si vous avez un clé API, c'est que vous êtes premium. Le problème que j'ai rencontré, comme d'autre d'ailleurs est que le test du type de compte ne semble pas très stable. Du coup, vous faites un test, ça fonctionne (ou pas d'ailleurs) et derrière votre user est banni. Du coup, quand vous lancer un téléchargement votre user n'est pas "valide" et si vous insistez, c'est votre IP qui est bannie. Pas de panique, ça revient après un moment (je ne sais pas combien, mais < 1h)

C'est effectivement surement ce qui explique ce que j'ai observé. Pour l'histoire des 100Mio/s, je vais continué de faire des tests croisés entre mon ordi et mes NAS pour voir... Mais en tout cas, j'ai pu lancer qq téléchargement de tests, ça fonctionne. Sinon, j'ai regardé l'API et... ben t'as tout fait, pour moi y'a rien besoin de plus dans ton script. Tout est là et c'est vraiment plus simple / clair / lisible que la version qui parsait les pages web 😅 Un grand merci.

Bonjour, déjà merci pour le travail, chez moi ça commencé à bloquer depuis hier, et j'ai remarqué que le script 3.2.5 récupérait une page (https://1fichier.com/console/index.pl) complète et cherchait entre autres variations "Compte offre Premium" hors, j'ai maintenant "Compte Premium" donc forcément, ça trouve pas. j'allais me faire un script qd j'ai vu qu'une version 4, basée sur l'API (c'est toujours plus simple normalement) avait été faite. (du coup j'ai pas regardeé les versions intermédiaires) sauf que là, c'est un peu la cata. Connaissez vous les limitations de l'API 1fichier (nb requetes max sur une période donnée) Je m'explique: J'ai installer le host 4.0.0 J'ai fait "vérifier", ça a fonctionné. Parfait. J'ai lancé un téléchargement, ça a échoué. Comme je ne voulais pas redémarrer mon NAS, j'ai juste stoppé le package dlStation, puis je l'ai relancé, j'ai essayé un autre téléchargement, j'ai reçu un fichier dont le nom était celui du lien et qui c'est avéré être la page html de dl de 1fichier demandant de se logger. j'ai retesté le compte, avec le bouton de vérification => échec comme c'est pas très précis, j'ai essayé un POST https://api.1fichier.com/v1/user/info.cgi dans postman ça m'a répondu KO, Flood detected, user blocked (oups) j'ai attendu un peu, genre > 1m j'ai relancé la requete ça m'a répondu OK, avec tous les détails (cool) j'ai attendu un peu, genre > 30s et relancé ça m'a répondu { "message": "Flood detected: IP Locked #41", "status": "KO" } re oups ensuite j'ai écrit tout ce message et re-testé depuis postman et ça refonctionne (en tout cas au moins ce endpoint de vérif) Du coup, là c'est un peu pénible, mais c'est surtout pour la suite, car là j'ai littéralement fait 4/5 requêtes en tout. Il va se passer quoi si j'ajoute 10 liens d'un coup, je suis ban pour un mois 😅 Du coup je suis preneur de vos retours: suis-je le seul, connaissez vous les limites,... Merci. A et dernière chose (que je viens de constater en faisant qq essais) est-ce bien la même url finale qu'avant qui est utilisée? Bizarrement, le téléchargement semble bloqué à ~100Mo/s. jusqu'à hier j'ai la majorité du temps à ~350Mo/s sur mon NAS et sur mon PC, qui n'est "que" en 2.5Gbits/s le même lien (lancé juste avant ou juste après) part directement à ~200Mo/s

un grand merci, surtout que depuis j'ai aussi eu des problèmes (du même type) avec downloadStation qui ne me permettait pas de créer le répertoire par défaut pour les downloads. du coup, maintenant je sais de quoi il retourne et je vais pouvoir me renseigner et en savoir un peu plus, car je connaissais pas du tout les ACL, juste les droits "posix"et encore pas le "X"

Bon un petit post pour essayer de comprendre. Il y a peut-être déjà tout (désolé si c'est le cas) mais j'ai pas trouvé. ce que je veux : me connecter en ssh, par clé publique et non pas par mot de passe. je le fais déjà sur un autre NAS (1511+) et sur plusieurs raspberry. La situation : un nouveau NAS (1817+) mêmes clés publiques (puisque je me connecte depuis les mêmes machines) .ssh créé dans le ~/.ssh de l'utilisateur /etc/ssh/sshd_config configuré "correctement" ~/.ssh en 700 ~/.ssh/authorized_keys en 600 Le problème : lorsque je tente de me connecté via ssh (linux, osx) il me demande le mot de passe lorsque je tente depuis avec putty (il est plus explicite) il me dit Server refused our key, puis demande un mot de passe Ce que j'ai vu et fait pour que ça marche : les droits du répertoire ~ de l'utilisateur sont : drwxrwxrwx+ ne connaissant pas cette notation j'ai fait un chmod 700 ça a fonctionné Ce qu'il faut faire pour revenir à cette situation : aller dans homes sur filestation clic droit / propriétés sur le home de l'utilisateur concerné Onglet permission cliquer sur options avancées / inclures les permissions héritées les droits de ~ repassent à drwxrwxrwx+ et l'accès est à nouveau refusé Du coup je me doute bien que c'est un problème de droit, mais j'avoue ne pas vraiment comprendre ou s'applique la restriction / quelle en est l'origine Mes questions : quelle est la restriction qui joue ici que signifie drwxrwxrwx+ mon action est-elle "dangereuse" et si oui comment concilier une configuration sécurisée comme à l'origine et un accès ssh par clé publique. D'avance merci pour vos lumières !

pour moi aussi la recherche de mise à jour me dit que je suis à jour, sans aucune erreur retournée (même sur mon nouveau NAS). et au boulot (adsl orange) ça semblait fonctionner, mise à jour de package OK, mais impossible par exemple d'installer MariaDB 10 pour pouvoir mettre à jour phpmyadmin ou mediawiki. chez moi, j'ai reçu mon nouveau NAS vendredi du coup il n'a jamais pu lister de paquets et c'est toujours impossible. c'est pas franc franc comme problème en espérant que ça se résolve rapidement "tout seul" avec la propagation des DNS et BGP...

Chez moi (ADSL Free), sur le nouveau NAS rien. sur l'ancien, il affiche la liste mais c'est tout... Au boulot (ADSL Orange), sur un NAS rien, impossible de lister des paquets, sur l'autre des mises à jours étaient dispo et j'ai pu les faire, sauf phpmyadmin & mediawiki qui nécessitaient MariDB 10, qui n'était pas listé dans les paquets "connus" et pour le coup, impossible de mettre à jour le listing des paquets pour avoir maria DB 10 et donc faire les mises à jours. MariaDB 5 lui par contre a bien pu être mis à jour... Impossible aussi d'avoir les paquets de synocommunity (mais attention, ça n'a peut-être/surement) rien à voir, je ne sais pas... bref, wait & see

dommage que les serveurs ne tiennent pas le choc, j'ai reçu aujourd'hui un nouveau nas pour relayer l'actuel un peu à la peine et du coup ça coince... enfin pas grave il fait beau, c'est pas comme si on était en mode tanière en plein hiver...

Bonjour, j'ai configuré webdav pour échanger facilement des petits fichiers. Sauf que je peux récupérer des fichiers depuis chez moi, en envoyer MAIS il m'est impossible de renommer les fichiers ou répertoire à distance. Je peux par exemple aussi créer un répertoire, mais pas lui donner un nom, il se nommera donc forcement "Nouveau dossier" une idée ? d'avance merci !

Bon trouvé... J'ai pas mal joué avec la config nginx et notamment pour augmenter la sécurité (dhparam,...) toujours est-il que dans le fichier proxy_default.conf, le paramètre était commenté, suite à une modification ou par erreur je ne saurais pas le dire, toujours est-il que avec le paramètre actif entry.cgi avec les arguments api=SYNO.Core.Desktop.Initdata&method=get&version=1 semble lu depuis un cache local et la page complète pèse environ 300ko, sans, entry.cgi avec ces mêmes paramètres est entièrement retéléchargé chaque fois et le site pèse environ 1,3Mo, d'ou un temps de chargement à +10 secondes. Attention donc... en espérant que ça en aide d'autre, Bonne journée !