Voilà un peu plus d’un an déjà, je déposai ici l’annonce d’une plate-forme ultra légère (id est : sans SGBDR et moins de 1 000 lignes de code) pour le partage de documents. Cette initiative faisait suite au 1ᵉʳ confinement et voulait donner un outil aux collègues enseignants qui soit à la fois respectueux du RGPD sans être une usine à gaz. C’est-à-dire, ni Dropbox, ni Nextcloud.
Voilà donc le 2ᵉ confinement (je ne parle pas des couvre-feux successifs) et cela me donne l’occasion de faire le point à douze mois.
Je tiens à remercier toutes les personnes pour leurs encouragements, leurs propositions et leurs retours (notamment notre regretté collègue et libriste Olivier Lecluze avec qui j’ai pu échanger sur QDRep).
Quoi de neuf depuis ?
D’abord que QDRep en est à sa version 2.5.
Cette version intègre un serveur d’instances pour que chacun puisse administrer son propre partage sur une même machine. Puis une gestion beaucoup plus fine des droits d’accès avec la possibilité de donner un ID et mot de passe à des utilisateurs. L’import de dossiers téléversés par FTP a également été ajouté. Voilà pour les grandes évolutions. Je vous laisserai découvrir les autres évolutions mineures si cela vous intéresse.
Cette dernière version tourne toujours sans SGBDR avec moins de 2 500 lignes de code. La facilité de mise en œuvre reste un souci majeur. Il est toutefois nécessaire d’avoir un serveur qui interprète PHP 5+ (un grand classique) avec le module OpenSSL activé. Cette dernière option n’est pas obligatoire mais est nécessaire dans le cas où vous souhaiteriez utiliser les listes à contrôle d’accès.
Voilà, c’est tout pour cette fois. On se dit alors à l’année prochaine pour un futur 3ᵉ confinement (?).
Aller plus loin
- Ancienne dépêche (166 clics)
- Le code source (708 clics)
- La doc, fichier pdf à télécharger (276 clics)
- Sur Framasoft (464 clics)
- Le bac à sable (693 clics)
# Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Quick & Dirty ?
Posté par lord_doom . Évalué à 2.
Bonjour Bruno,
comme QDRep est un logiciel libre, tu peux faire une revue de code. Je te laisse juger par toi-même. Mais dans l'urgence de l'époque, oui, c'est du Quick et, malgré tout, un peu Dirty ;-)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Quick & Dirty ?
Posté par lord_doom . Évalué à 4.
Ben si justement, ça permet de corriger les bugs et de faire avancer les choses.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 9.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Quick & Dirty ?
Posté par Thomas Debesse (site web personnel) . Évalué à 8.
Idem, je t’ai envoyé un courriel sur l’adresse présente dans le code source à partir de mon adresse pro.
J’y décrit également ce que j’ai pu faire, mais pas ici…
Dans ta présentation tu dis:
L’idée de protection des données dans “RGPD” ce n’est pas seulement une question de qui a connaissance de quoi, le fait qu’un tiers ait inutilement connaissance de tes factures pourrait être moins pire sur le plan RGPD que par exemple la corruption de donnée visant à produire des données altérées de facturation t’engageant pénalement, quand bien même celui qui opérerait les altérations n’aurait pas connaissance des données elle-mêmes.
Cela dit, je trouve l’outil facile d’accès et à utiliser, c’est un bon point et un objectif qui semble atteint. Mais il y a visiblement d’autres objectifs en approches. =)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Quick & Dirty ?
Posté par lord_doom . Évalué à 7.
Bonjour Thomas,
j'ai pris connaissance de tes méls et je te remercie pour toutes tes remarques très justes et très pertinentes. Je ne sais pas si le vol de données personnelles est moins pire que la corruption de données. De mon point de vue je les place sur le même plan. De toute façon il est d'une importance capitale de corriger les bugs de sécurité que tu as soulevés (de même Bruno que je remercie également au passage).
Je vais donc m'atteler le plus tôt possible à un correctif. Évidemment, si des lecteurs souhaitent donner un coup de main et participer au projet, vous êtes les bienvenus ! Actuellement je suis seul et j'avoue que pouvoir échanger comme maintenant avec d'autres personnes c'est sympa.
Dans l'immédiat, je retiens que les problèmes de sécurité ne sont pas triviaux et qu'il est important de les prendre en compte dès le départ (ie: Security By Design). Chose sur laquelle je suis passé un peu vite. J'avais bien dit que c'est du Quick and Dirty…
Bon, il va falloir maintenant arranger tout cela.
[^] # Re: Quick & Dirty ?
Posté par Christophe . Évalué à 10.
Juste une remarque sur ce point: je pense que ne pas utiliser d'outil de gestion de code (à la gitlab ou autre) est un gros frein pour attirer d'éventuels contributeurs.
On ne sait pas trop comment proposer des modifications, impossible de savoir s'il y a des modifications en cours, impossible de voir l'historique, pas de visibilité sur les problèmes ou idées remontées… Tout cela va probablement décourager les curieux.
[^] # Re: Quick & Dirty ?
Posté par lord_doom . Évalué à 1.
Bonjour Christophe,
jusqu'à présent je suis seul et j'utilise git en local ; d'autant plus que le projet est minuscule (~2000 lignes de code). Je ne voyais pas trop d'intérêt de publier sur une forge. Si tu es intéressé, envoi-moi un mél et on publie sur Gitlag si tu es d'accord. Tu peux même publier toi-même les sources et me mettre en contributeur.
Encore une fois, toutes les bonnes volontés sont les bienvenues, chacun peut prendre des initiatives et les faire partager. Donc, si le projet vous intéresse ne vous posez pas trop de questions et rejoignez moi (nous ?).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4. Dernière modification le 28 avril 2021 à 17:46.
Ce commentaire a été supprimé par l’équipe de modération.
# Licence
Posté par barmic 🦦 . Évalué à 6.
Il n'y a pas de mention de licence, il semble qu'elle a changée depuis la dernière dépêche. Elle est passée de GPL à AGPL.
2.5b d'après l'archive, tu utilise quoi comme versionnent ?
Ce serait bien que l'archive contienne la version dans son nom.
C'est très cool d'utiliser son propre logiciel pour fournir son logiciel, mais ton instance me semble plus critique que celle de tes utilisateurs. Il serait utile d'utiliser un minimum de sécurité en plus. Signer l'archive serait bien, mais à minima donner le checksum de l'archive.
Je sais pas si c'est la dépêche qui est très en retard ou s'il y a une volonté forte d'ignorer le deuxième confinement.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Licence
Posté par lord_doom . Évalué à 2.
La toute 1ère version était en GPL, peu de temps après je suis passé en AGPL.
La licence est mentionnée quand tu cliques sur le lien QDRep an bas de la page, il y a un fichier COPYING dans les sources et les sources contiennent la référence à la licence avec une en-tête SPDX.
Le versionnement se fait de la façon suivante : .
quand la release arrive à 9, le majeur est incrémenté de 1
les correctifs s'incrémentent alphabétiquement
Tu as raison sur le nom de l'archive mais je ne veux pas casser le lien donné sur les sites où il a été publié (je pourrai passer par un lien symbolique mais je n'ai pas accès au shell sur le serveur).
Tu as raison aussi sur le problème de sécurité.
QDRep étant un tout petit projet, utilisé par moins de 500 personnes en production, je n'ai pas jugé utile de le faire (je suis paresseux quoi, j'ai fait vite - Quick ;-)).
J'ai sans doute tort.
[^] # Re: Licence
Posté par barmic 🦦 . Évalué à 3.
Oui oui c'est comme ça que je l'ai vu. C'est plus dans la dépêche (d'autant plus quand la licence a changée d'une dépêche à l'autre).
D'acc
Je comprends. Si c'est un apache, peut être qu'une redirection temporaire via le fichier
.htaccesspeut faire l'affaire ?Je ne te blâme pas. J'essaie juste de donner quelques pistes d'améliorations :)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# SGBDR
Posté par Papey . Évalué à 6.
Salut,
je ne sais pas en quoi un SGBDR pourrait être utile ou pas, mais si ça peut effectivement être utile et que la raison pour laquelle tu ne veux pas en mettre est que tu souhaites optimiser l'architecture, la maintenance et l'exploitation de ton logiciel, SQLite pourrait être un bon candidat malgré tout. SQLite est une simple bibliothèque et ne nécessite pas d'autre service que le programme PHP qui tourne déjà. Sauf évidemment si c'est le SQL qui te gêne, là c'est sûr que ça n'aidera pas :-D.
[^] # Re: SGBDR
Posté par lord_doom . Évalué à 5.
Bonjour,
le SQL ne me dérange pas, bien au contraire, c'est le SGBDR. Je m'explique.
Si on utilise un gestionnaire de base, il faut sauvegarder la base en plus de l'application, la config et les données (en cas de pb ou de migration). Si on n'a pas accès aux tables, il faut les exporter, puis les importer. C'est faisable, et ça se fait régulièrement, mais c'est plus complexe à mettre en œuvre. Que je n'ai pas la volonté de faire ; je souhaite rester dans l'esprit du KISS.
Dans le cas de SQLite, on a accès à toute la base mais. Cela peut poser des pb de sécurité (déjà que… voir discussion ci-dessus) et j'ai lu qu'il y a d'éventuels soucis d'accès concurrents. Des solutions d'optimisations sont fournies, surtout en lecture, mais je n'ai pas envie d'avoir un "bug" lorsque 30 élèves déposent leurs travaux en même temps à la fin de la séance de cours/TP/TD… Je préfère rester prudent (injustement peut-être).
L'idée est de pouvoir sauvegarder l'ensemble du site par ftp et de le migrer en un clic de souris tout en ayant un accès direct aux fichiers par un explorateur de fichiers également. Bref, une solution sans "prise de tête".
C'est un choix de conception. Je ne dis pas que c'est le meilleur mais il est guidé dans un objectif de simplicité et de rapidité.
[^] # Re: SGBDR
Posté par Papey . Évalué à 5. Dernière modification le 04 mai 2021 à 09:33.
Je comprends tes choix et SQLite ne permettra effectivement jamais (sauf à inclure la bibliothèque dans de prochaines version des explorateurs de fichiers) d'explorer les données sans programme dédié.
Quelques précisions par rapports aux autres points évoqués. A partir du moment où aucune transaction en écriture n'est en cours tu peux sauvegarder une base SQLite en copiant simplement le fichier de la base, par FTP ou par un autre moyen, en même temps que les autres fichiers de l'application. Et en général même si une transaction en écriture est en cours, le fichier ne sera pas corrompu, même si en toute rigueur ce n'est pas garanti.
Pour ce qui est des accès concurrents, ce qui est problématique c'est lorsque plusieurs processus différents essaient d'accéder au même fichier SQLite à travers le réseau, à partir d'ordinateurs différents. Ce sont les imperfections de la gestion des accès à des systèmes de fichiers distants par les systèmes d'exploitation qui ne garantit pas que toutes les modifications apportées dans ce cas le seront de manière cohérente : SQLite ne peut pas imposer explicitement un vidage des tampons à la fin des transactions avec l'assurance que les modifications seront effectivement écrites physiquement sur le support cible. Chaque ordinateur pourra donc potentiellement avoir une vision un peu différente du fichier SQLite.
Cependant si un logiciel serveur centralise les accès via le web à l'application, et que seule l'application accède à la base de données, a priori la base SQLite est soit sur le disque physique associé à l'ordinateur où tourne l'application, et la bibliothèque SQLite peut donc s'assurer du vidage effectif des tampons, soit l'application utilise la même pile d'accès à un répertoire réseau, et a priori les différents processus / threads devraient avoir la même vue sur l'état du fichier, mais cela dépend peut-être du protocole réseau utilisé et de sa manière de gérer localement les accès concurrents aux ressources distantes.
Dans le cas où SQLite peut contrôler efficacement les tampons d'accès en écriture à la base de données, il n'y a aucun problème de concurrence : SQLite est pleinement ACID, chaque processus a une vue purement transactionnelle sur la base et les différents processus ou threads font simplement la queue pour écrire dans la base, avec en général de très bonnes performances.
Quoi qu'il en soit, dans de nombreux cas les accès concurrents à une base SQLite sont plus simples à gérer que des accès concurrents à d'autres types de fichiers binaires ou texte, dans la mesure ou SQLite gère pour toi les mécanismes de gestion de la concurrence (mutex ou autres), et que les problèmes d'asymétrie dans les accès au réseau touche aussi les autres types de fichiers que tu pourrais utiliser.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.