Chères moules, poulpes et autres pinnipèdes,
Depuis un petit moment je ne suis plus satisfait par ma méthode ancestrale de partage de fichiers, qui consiste à exécuter la commande suivante dans mon terminal préféré :
scp mon-fichier.png ssz.fr:http/ssz.fr/www/brdl/fichier.png
Pour autant, aucune des solutions que j'ai pu trouver en ligne n'ont été jusqu'ici à la hauteur de mes espérances. Vendredi dernier j'ai justement eu l'occasion de tester une de ces solutions, qui ne marche bêtement pas sans Javascript. Je dis bêtement vraiment parce que faire un lien vers l'url actuelle avec &p=1
en plus et qui fonctionne sans Javascript, c'est clairement possible.
-
Jirafeau — https://gitlab.com/mojo42/Jirafeau
C'est simple et classe, certes, mais Javascript est nécessaire pour télécharger les fichiers partagés (!) qui ne sont, après upload ou partage d'un lien, pas disponibles par un lien direct. Ajouter&p=1
dans l'url donne le résultat recherché. Le code semble relativement acceptable mais les téléchargements doivent impérativement passer à traversf.php
ce qui occupe un précieux process PHP pour rien. -
Pomf.se et ses nombreux clones — https://github.com/pomf/pomf
Simple et classe d'apparence aussi, mais côté utilisateur il faut aller sur une page spécifique pour que ça marche sans Javascript, et côté admin il faut quand même compiler des trucs et ça utilise une base de données. -
Uguu.se — https://github.com/nokonoko/uguu
Euh bon j'avoue, ça marche bien, sans Javascript aussi, sans base de données, ça a l'air bien, mais euh j'aime pas trop l'aspect, trop de CSS à mon goût. Et sans JS, on ne voit pas quand un fichier a été choisi. -
Shareit
Bon c'est du Python -
Lufi — https://framagit.org/luc/lufi
Bon c'est du Perl -
Jb3 — https://github.com/devnewton/jb3
Bon c'est du Java
Bref. Il y en a d'autres, mais rien de trop trop intéressant et facile à mettre en place, ou qui réponde vraiment à ce que je cherche, en tout cas dans ce que j'ai trouvé.
Du coup j'en ai écrit un, en PHP, sans Javascript et sans base de données, j'ose espérer qu'il est aussi simple que possible.
Donc voilà : jus - Just Upload Stuff.
C'est du GPLv3, le code est ici : https://github.com/seeschloss/jus compatible PHP5.6, pour Free, et sans dépendance particulière. Mon instance publique est ici : up.ÿ.fr (et mon test sur un hébergement Free : schee.free.fr/jus).
L'idée, c'est de pouvoir le mettre sur n'importe quel type d'hébergement un peu potable (même les pages perso Free !) sans trop avoir à configurer quoi que ce soit, mais quand même de pouvoir aussi faire quelque chose de propre comme pour chez moi avec un domaine séparé pour servir les fichiers, les sources et la configuration en dehors du document root, le support du PUT, etc.
Les détails d'administration à mon avis n'ont pas leur place dans le code de l'application : pour enlever les fichiers après un certain temps, un cronjob fera l'affaire, pour limiter l'accès à l'upload ou au téléchargement, pourquoi pas simplement de l'authentification HTTP gérée par le serveur (même si je pense que de l'auth OAuth2 pour limiter l'accès aux utilisateurs de DLFP par exemple pour joindre des fichiers sur la tribune pourrait être intéressante, par exemple).
Côté utilisation, l'upload juste marche sur l'interface web, et curl
permet d'uploader un fichier vraiment facilement grâce à --upload-file
(ou -T
) :
curl --upload-file <fichier> https://up.ÿ.fr
qui répond simplement avec l'url du fichier uploadé.
Pour les installations sur des serveurs où on ne maîtrise pas tout et où on ne peut pas utiliser de PUT, ça reste assez simple :
curl -F file[]=@<fichier> https://up.ÿ.fr
qui permet aussi de multiplier les -F file[]=
pour uploader plusieurs fichiers à la fois.
J'ai hésité et finalement décidé de ne pas ajouter de header inconditionnel Access-Control-Allow-Origin: *
qui aurait pourtant permis d'uploader des fichiers directement en Javascript à partir d'un autre serveur sous un autre domaine, mais ça viendra peut-être si on me convainc que c'est utile.
Dans les fonctionnalités que j'imagine ajouter dans le futur, je pense à :
- permettre authentification OAuth2 auprès de DLFP ou autres
- permettre la suggestion d'un nom de fichier au lieu de forcément en générer un aléatoire côté serveur
- ajouter une barre de progression à l'interface web
- permettre le copier-coller et le drag-and-drop (avec du Javascript du coup)
- ajouter un gros message en rouge clignotant pour indiquer que faire confiance à un serveur d'upload pour chiffrer des fichiers de son côté, c'est vraiment naïf et que si vous voulez que vos fichiers soient chiffrés, faites-le vous-même avant de les uploader.
Au passage, Let's Encrypt ne supporte toujours pas les noms de domaine avec des accents, c'est pénible.
# 2 questions bêtes
Posté par finss (site web personnel) . Évalué à 4. Dernière modification le 18 septembre 2016 à 20:57.
Cher See< (à prononcer zée< NDLR)
Si Let's Encrypt ne supporte les accents, comment as tu fait pour https://up.ÿ.fr/ ?
Comment prononces-tu ÿ.fr ?
\_o<
[^] # Re: 2 questions bêtes
Posté par BFG . Évalué à 2.
Il ne semble pas utiliser letsencrypt pour son certificat.
[^] # Re: 2 questions bêtes
Posté par 못 옷 홋 ♨ (site web personnel) . Évalué à 4.
J'ai été obligé de me rabattre sur Wosign, un fournisseur (chinois, oulala ça fait peur) de certificats SSL gratuits et valides pour trois ans.
C'est plus pratique que StartSSL que j'utilisais avant Let's Encrypt, mais après avoir goûté à LE c'est vraiment pénible de revenir à un process tordu d'inscription, validation, téléchargement des certificats, envoi sur le serveur, et installation.
Pour la prononciation, j'ai envie de partir sur un simple "i" point fr, voire "i grec" si on veut faire du zèle. De toute façon, 99% des autres idiots qui ont acheté des noms d'une seule lettre en .fr n'en font rien, y compris i.fr et y.fr, donc ça n'a pas d'importance : je suis de facto le seul "i point fr" qui compte.
[^] # Re: 2 questions bêtes
Posté par finss (site web personnel) . Évalué à 1.
C'est des chinois gentils ou des chinois méchants ?
Perso, j'hésitais entre le i grec tréma, que je trouve fort moche et le son u associé au y en allemand. Ce u très aigu. Va-t'en savoir ce qui m'y a fait penser…
\_o<
[^] # Re: 2 questions bêtes
Posté par 못 옷 홋 ♨ (site web personnel) . Évalué à 4.
Disons qu'il y a plus respectable :
https://www.schrauger.com/the-story-of-how-wosign-gave-me-an-ssl-certificate-for-github-com
Mais en fait, le manque de responsabilité d'une autorité ne change pas grand chose pour les utilisateurs de ses services en particulier, ça rend "juste" tout le système SSL moins fiable. Du coup, utiliser leurs certificats, en soi, ne pose pas vraiment de problème pour celui qui les utilise.
[^] # Re: 2 questions bêtes
Posté par karteum59 . Évalué à 3. Dernière modification le 19 septembre 2016 à 23:27.
Sauf quand ta CA se fait virer des navigateurs ;)
# Jirafeau et javascript
Posté par Anonyme . Évalué à 6.
Il me semble que l’intérêt de Jirafeau est de pouvoir s'affranchir de la limite d'upload du serveur en envoyant le fichier en plusieurs morceaux grâce à javascript.
Or, si je ne m'abuse, ta solution se cogne la tête sur la limite d'upload du serveur.
[^] # Re: Jirafeau et javascript
Posté par 못 옷 홋 ♨ (site web personnel) . Évalué à 3.
C'est fort possible !
Mais étant admin moi-même, je ne suis pas fan des solutions de ce type pour contourner des limites système, surtout quand ça nuit à mon user experience.
[^] # Re: Jirafeau et javascript
Posté par Mikis . Évalué à 4.
Ben attention à ton hébergement free.fr qui n'est pas trop fan des usages différents des bêtes pages html.
[^] # Re: Jirafeau et javascript
Posté par 못 옷 홋 ♨ (site web personnel) . Évalué à 1.
C'est juste pour montrer que ça fonctionne aussi sur des hébergeurs pourris. Si jamais il y a plus de deux fichiers uploadés dessus par mois, je l'enlèverai et puis c'est tout.
# BoZoN
Posté par Benoît Laurent (site web personnel) . Évalué à 3.
J'utilise Bozon que je trouve bien pratique. PHP 5.2 min, pas de base de donnée. Je ne sais pas comment il se comporte sans Javascript par contre, il en utilise quand même pas mal.
# Fotoo Hosting
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 6.
http://dev.kd2.org/fotoo/Fotoo+Hosting le fait :)
Marche aussi sans JS, mais si JS est dispo ton image sera redimensionnée avant envoi, pratique sur connexion lente et en plus ça limite la charge serveur :) A ma connaissance c'est le seul à faire ça, dommage que les autres ne le fassent pas.
Démo : http://dev.kd2.org/fotoo/Fotoo+Hosting
Upload en CLI:
curl -i -F name="Image title" -F private=0 -F upload=@mypicture.jpg http://fotoo.example.com/?upload | grep '^Location' | sed 's/^Location: //'
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
# Précisions
Posté par mojo42 . Évalué à 10.
Bonjour,
Concernant Jirafeau:
Comme le montre l'image ci-dessous, Jirafeau permet de télécharger un fichier sans javascript
Il est également possible d'uploader un fichier sans javascript mais la taille d'envoie sera limité selon la configuration du serveur. Javascript permet d'envoyer plusieurs morceaux de fichiers et donc d'envoyer de gros fichiers même si le serveur est configuré avec un petit envoie.
C'est le prix à payer pour ne pas avoir une URL vers le fichier directement et pouvoir le protéger par un mot de passe ou limiter son accès dans le temps :)
Librement,
Mojo (créateur de Jirafeau)
[^] # Re: Précisions
Posté par 못 옷 홋 ♨ (site web personnel) . Évalué à 4.
Alors oui, on peut télécharger les fichiers sans Javascript avec
&p=1
(ou&d=1
comment je vois sur ta capture d'écran) mais, c'est à la personne qui les partage de faire ce choix.En tant qu'utilisateur qui tombe sur un lien partagé par un autre utilisateur sur une tribune, je me suis retrouvé avec une page :
qui contient deux boutons qui mènent à la page suivante si Javascript n'est pas activé :
Donc je me suis dit "Fichier envoyé !" cool, mais où ? Et aucun indice pour savoir comment faire pour arriver au fichier. Effectivement en regardant la source de la page précédente, on voit des
onclick=
qui donnent les URL avec&d=1
et&p=1
mais ce n'est pas évident : je pense que des<a>
avec unehref
idoine seraient plus efficaces que des<input>
dans le cas présent.Maintenant, je ne cherche pas à basher Jirafeau du tout :) je sais que la plupart des utilisateurs auront toujours le Javascript activé, et il propose bien plus de fonctionnalités que mon petit projet, et c'est très bien, par contre ce n'est pas ce que je recherchais.
Tu as juste eu le malheur d'être l'élément qui m'a fait décider d'écrire le mien ! En fait je pense que l'élément principal de ma démarche, c'était de réussir à trouver un moyen de rendre un formulaire d'upload simple et pas trop moche sans recours au CSS. Il y a de quoi s'améliorer encore, mais pour l'instant je suis relativement satisfait.
[^] # Re: Précisions
Posté par mojo42 . Évalué à 2. Dernière modification le 19 septembre 2016 à 15:39.
Hello,
Sur le dernier screenshot, c'est toute la présentation de la page web qui part en sucette donc tu vois à peu prêt tous les écrans d'affichés en même temps :)
On peut dire que c'est un bug graphique, mais pour moi l’intérêt de pouvoir télécharger sans JS, c'est de pouvoir le faire dans un script/application, pas dans un browser.
Les cas où les users refusent d'activer du JS dans leur browser, c'est tout de même assez minoritaire.
C'est comme fournir un support pour IE6: c'est fatiguant et il y aura toujours un user pour le réclamer.
T'inquiètes pas, je suis toujours content de voir de la prolifération sur d'outils libres qui peuvent aider les gens, ce n'est juste pas le même but :)
[^] # Re: Précisions
Posté par Anonyme . Évalué à 8.
non: dans un cas ça s'appelle 'prise en charge de l'accessibilité du web et respect de tous ses usagers' dans l'autre 'prise en charge d'un navigateur irrespectueux du web et de ses usagers'
[^] # Re: Précisions
Posté par mojo42 . Évalué à 2.
Mon point n'est bien évidement pas de refuser d'améliorer l'accessibilité, c'est juste qu'il y a une question de priorité et d'investissement temps (et quand on sait ce qu'il ne va pas), pas de "respect".
Pour l'exemple qui a été donné, je pense pas que ça soit très difficile de corriger pour rendre la page correcte sans JS, il faut juste le faire :)
# Just Upload Stuff
Posté par devnewton 🍺 (site web personnel) . Évalué à 9.
Bon c'est du php
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Multiprotocole
Posté par barmic . Évalué à 5.
Il faut que je me penche là dessus, parce que je ne suis pas non plus satisfait de ma solution…
J'aimerais personnellement avoir de l'envoie scp, https, bitorrent ou synthings et de la récupération bitorrent ou https avec une interface d'admin pour gérer tout ça.
bt est super pratique pour la manipulation de très gros fichiers (genre 5Gio et plus) pour la performance, mais aussi pour la gestion de la bande passante et pour la reprise du transfert.
Ce serait génial, mais ce ne sera de toute manière pas aussi pratique à mettre en place.
Merci du partage ! :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Ma solution
Posté par LaBienPensanceMaTuer . Évalué à 1.
A l'époque, je m'étais codé en C un petit bout de programme basé sur inotify et qui surveillait le répertoire $HOME/to-upload/
Dès qu'un fichier était posé dans ce répertoire, mon petit programme était notifié et je lançais, de mémoire, un rsync (le pré-requis étant que la clef SSH soit installée sur le serveur distant et que ssh-agent tourne).
Ca marchait plutôt pas mal.
J'ai découvert plus ou moins récemment qu'un daemon existait (de base dans debian depuis quelques années) qui fait exactemenet ce boulot, mais avec un côté bien plus configurable: incrond (http://inotify.aiken.cz/?section=incron&page=doc&lang=en)
[^] # Re: Ma solution
Posté par kna . Évalué à 3.
Ou plus simple dans ce cas : lsyncd (c'est dans debian aussi)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.