Mais si tu tapes https://g1.syoul.fr, on tombe sur le login de yunohost. Peut-être que l’API est disponible sur un port différent, ou sur une url différente ?
Ğinspecte et Césium ne gère pas le chemin où se trouve l’API BMA.
Ğinspecte génère ce lien pour https://duniter.moul.re/bma/:443 pour mon nœud.
Césium devrait trouver ton bma sur https://g1.syoul.fr/bma/ sur /network/peerings, mais /bma/ est absent.
Spécialité du paquet YunoHost pour casser les pieds des autres développeurs, non je plaisante. C’est le compromis que j’ai choisi, car ça permettait d’avoir la CI qui passe et que le paquet soit présent dans le catalogue d’apps YunoHost.
bon maintenant tous les noeuds yuno sont visibles, mais les autres à la trappe.
Bravo @jnoel tu es sur la bonne piste, mais cela doit être le casse tête.
non, je n’y ai pas touché cette nuit. C’est juste ce matin que je m’y suis mis.
Mais comme je suis à la Réunion, il y a 3 heures de moins plus qu’en france.
Merci @Moul pour la recherche de bug, c’était bien le port que je ne mettais pas au bon endroit.
J’en ai profité pour mettre ginspecte en mode production avec une vrai base de données (sqlite → postgresql).
Dans le processus, on repart de zéro concernant l’historique des tests… mais il se remplira vite.
wOw! Cool les noeuds Yunohost apparaissent bien dans la liste, super ! Ça serait génial si on pouvait avoir la même chose dans la liste des noeuds sur Césium @kimamila ? Merci pour ce travail
J’ai préparé la gestion des utilisateurs dans Ǧinspecte.
Il faudrait établir le comportement qu’on attend du logiciel :
seuls les admins ont un compte et peuvent écrire (ajout, modification, suppression), les visiteurs sont en lecture seule
seuls les admins ont un compte. Les visiteurs sont en lecture seule mais peuvent remplir une demande d’ajout de service qui devra ensuite être validée par un admin pour apparaitre.
tout le monde peut s’inscrire et tout modifier (l’inscription permet juste de limiter un peu les robots et de tracer les actions)
tout le monde peut s’inscrire et ajouter des services mais ne pourra modifier/supprimer que les services qu’il a créé. Des utilisateurs avec des droits supplémentaires (admin) pourront eux avoir la main sur toutes les entrées.
Ça dépend des ambitions qu’on a pour Ğinspecte (par exemple si on veut le conserver en v2) mais une solution simpliste avec un unique compte admin dont on partage les codes convient tout à fait.
Et ensuite il faudrait plutôt partir sur une authentification à l’aide de clés Ğ1, ce serait plus logique par rapport à la direction dans laquelle on veut aller.
Non, ce n’est pas l’architecture que j’imagine. Plusieurs idées :
soit le service centralisé publie un jeton d’authentification chiffré pour la clé ciblée
soit le service centralisé demande de signer un challenge (par ex avec Ğ1 companion) et en cas de succès retourne un jeton d’authentification
soit le service centralisé wrappe son API dans quelque chose qui vérifie la signature de chaque payload, et le frontend utilise l’API Ğ1 companion pour solliciter les signatures
Il ne faut pas envisager la sécurité crypto comme la sécurité à secret, mais en utilisant les fonctionnalités de chiffrement/déchiffrement et signature/vérification.
Je crois que ça arrive quand le scan n’est pas tout à fait terminé.
Ca doit se corriger tout seul au bout de quelques minutes.
Mais il manque effectivement une traduction, sinon on ne verrait pas ce message.
Je le note.
I’m trying to parse https://ginspecte.mithril.re/services.json from my client Ğ1nkgo in order to get an updated list of working nodes, but it seems that the generated url in the list is wrong. An extract: