mathieuandClaude Opus 5
d0ebecc233
Le manifeste de la 0.5.0, deja publiee, s'est mis a pointer une archive
introuvable — l'installation echouait sur ynh_setup_source, sans que le
symptome designe la cause.
Le remplacement global des URL avait reecrit amd64.url, c'est-a-dire
precisement le champ que la documentation ecrite le meme jour designait comme
« a ne jamais changer a la main », puisque publier.sh le regenere a chaque
publication.
⚠ L'erreur de conception est plus large : le placeholder avait sa place dans la
COPIE publique, pas dans le depot de travail, qui sert au deploiement reel et
doit rester operationnel. Anonymiser un depot qui sert encore, c'est le casser.
Ce qui reste, et qui vaut : depot_code commande toujours toutes les URL
derivees, et le garde-fou refuse toujours de publier avec une URL en
example.org — il ne se declenche simplement plus ici, puisqu'il sert a la copie
publique.
sha256 inchange : seule l'URL avait bouge, le manifeste retrouve exactement son
etat de publication.
--- L'installation ne demande plus qui a acces
init_main_permission quitte [install] au profit de
resources.permissions.main.allowed = "all_users". Verifie dans le coeur
YunoHost (src/utils/resources.py) :
init_allowed = infos["allowed"] or self.get_setting(f"init_{perm}_permission") or []
allowed L'EMPORTE sur la question. La garder l'aurait donc posee pour rien, en
laissant croire que la reponse comptait.
⚠ Ce n'est pas un reglage de confort : visitors casserait deux invariants du
code. L'application n'a aucune authentification propre — elle fait confiance a
YNH_USER parce que SSOwat l'ecrase a chaque requete, exactement comme elle
n'ecoute que sur 127.0.0.1 — et toute personne autorisee peut SUPPRIMER
n'importe quel livre du catalogue commun, sans role ni lecture seule.
⚠ Pas de protected = true, delibere : restreindre a un groupe dedie reste
legitime, et c'est l'affaire de l'administrateur. C'est l'elargissement qui est
un contresens, pas le reglage.
⚠ allowed n'agit qu'a la CREATION de la permission (if perm not in
existing_perms) : une montee de version ne realigne rien. Un commentaire de
manifeste n'atteignant aucun administrateur, l'avertissement vit dans
doc/DESCRIPTION.md (page d'installation) et doc/ADMIN.md (interface
d'administration) — les deux seuls fichiers du paquet que YunoHost lit lui-meme.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3.3 KiB
Où vivent les données
| Quoi | Où |
|---|---|
| Binaires et client web | /var/www/mabibli |
| Base SQLite | /home/yunohost.app/mabibli/mabibli.db |
| Journaux | journalctl -u mabibli |
La base est séparée des binaires : une mise à jour remplace /var/www/mabibli sans toucher
aux données, et le schéma est migré automatiquement au démarrage. Rien à lancer à la main.
Qui a accès
⚠️ MaBibli est une application privée
Elle n'est pas faite pour être publique. L'installation la règle sur
all_users— les comptes du serveur — et ne pose pas la question, parce qu'il n'y a pas de bonne raison de l'ouvrir plus large.N'ajoutez jamais le groupe
visitorsà la permissionmabibli.main.Deux raisons, et ce sont des propriétés du code, pas des préférences :
- L'application n'a aucune authentification à elle. Elle lit l'en-tête
YNH_USERque le portail YunoHost injecte à chaque requête, et lui fait confiance. Ouverte aux visiteurs, plus personne n'écrit cet en-tête : tout ce qui est personnel — statuts de lecture, liste d'envies — devient lisible et modifiable par n'importe qui.- Toute personne autorisée peut tout modifier, y compris supprimer des livres du catalogue commun. Il n'existe ni rôle, ni lecture seule, ni journal des suppressions. C'est assumé pour un foyer, dont les membres se connaissent.
Restreindre plus (un groupe dédié) est parfaitement légitime, et se fait dans les permissions YunoHost (
mabibli.main). C'est l'élargissement qui est un contresens.
MaBibli n'a pas de connexion propre : l'identité vient du portail YunoHost. Réglez les accès
dans les permissions YunoHost (mabibli.main), pas dans l'application.
La collection est commune à toutes les personnes autorisées. Les statuts de lecture sont personnels, les prêts sont communs.
⚠️ Ne jamais élargir l'écoute du service. Il écoute sur 127.0.0.1 uniquement, et c'est
une frontière de sécurité : l'application fait confiance à l'en-tête YNH_USER parce que
SSOwat l'écrase à chaque requête. Un service joignable directement permettrait de le forger.
Sauvegarde manuelle
La base est en mode WAL : un cp du fichier .db peut ne rien sauvegarder du tout.
sqlite3 /home/yunohost.app/mabibli/mabibli.db ".backup '/quelque/part/mabibli.db'"
yunohost backup create fait déjà ce qu'il faut, sans arrêter le service.
Ce dont le serveur a besoin
- Accès sortant HTTPS vers
catalogue.bnf.fretopenlibrary.org, pour pré-remplir les fiches depuis un ISBN. Sans lui l'application marche, mais toute saisie devient manuelle. - HTTPS pour le scan du code-barres : les navigateurs n'ouvrent la caméra qu'en contexte sécurisé. Le certificat Let's Encrypt de YunoHost suffit ; joindre le serveur par son IP locale fera toujours échouer le scan. La saisie manuelle reste disponible.
- Un domaine entier. MaBibli ne s'installe pas sous un sous-chemin : le client Blazor fige son chemin de base à la compilation, et rien n'est compilé sur le serveur.
Le détail — conception du paquet, publication, mise à jour pas à pas, retour arrière — est dans le README du dépôt du code.