Et apparemment ya pas mal de gens qui l’utilisent… Les utilisateurs sont ils conscient qu’ils fournissent leur clé privé à un tiers ? Que ce tiers peut se logguer sur leur compte ?!
Il faut absolument qu’il intègre des controles de sécurité… Vérification que le compte n’est psa un compte membre, message de warning annonçant d’utiliser obligatoirement un compte porte-feuille etc…
nop je ne connais pas se service et ne connais personne qui l’utilise. En tout les cas le créateur de service est soit malhonnête soit inconscient des problématiques de sécurité car en effet il devrait indiquer en rouge et en gros de ne surtout pas utiliser les identifiants de son compte membre, un message du style « Créez impérativement un simple portefeuille dédié a g1virement »
Très peu je sais que @PiNguyen et @Frederic_Renault le connaissent bien sur Toulouse, en tout cas c’est quelqu’un de sérieux et réputé pour ses compétences, ils tirent la fibre en asso autour de Toulouse, c’est un admin sys très impliqué dans la ML.
Il est dans axiom-team aussi, on peut lui en parler.
C’est bien Olivier Fontes. Un grand expérimentateur, et qui a réuni des 10aines de personnes de son village autour de l’usage de la June. Il fournit l’accès Internet en June Il doit organiser les virements des ses clients. Il a du leur dire de ne pas utiliser leur compte membre.
Faudrait arriver à remonter les TX pour contrôler ça.
Je lui en parlerait…
C’est fait côté Césium ? Je sais pas, je m’en sers pas. Ça serait bien plus prioritaire, non ?
Si c’est le cas, je pense que la licence GNU AGPLv3, utilisée par Silkaj, lui oblige à préciser quel logiciel est utilisé sous le capot et à publier sa version modifiée si c’est le cas.
Le service n’est pas utilisé pour le moment, je ne l’utilise qu’à des fins internes pour le moment afin de justement voir comment on peut mettre en place un outil de ce type. Je l’ai ouvert en début de semaine à PI pour qu’il me fasse un retour, et finalement 2 jours plus tard, j’ai plein de retours pertinents notamment sur la problématique de sécurité et de licence.
L’idée de base étant de répondre à un problématique de récurrence de virement, comme je vend de la connexion internet en Ḡ1, je me suis assez vite rendu compte que les gens oublient a peu près systématiquement d’effectuer les virements mensuellement, ce qui m’engendrait des coûts humains en « recouvrement », donc une connexion internet en Ḡ1 me coûte plus qu’une connexion en €.
Pour vous décrire un peu comment il fonctionne, c’est un bout de code en php qui utilise silkaj en dessous et le système d’authfile pour ne pas avoir à stocker d’identifiants, les virements sont stockés dans une bdd mysql et lancés par un cron.
Afin effectivement d’éviter que des gens ne l’utilisent sans information j’ai désactivé le service pour le moment, je le remettrai en route une fois que j’aurai amélioré les différents aspects évoqués dans ce post.
Merci pour ce retour Olivier C’est un outil qui a du potentiel effectivement, l’objectif n’était pas de le dénigré… Mais d’éviter qu’il soit diffusé “trop tot”
J’ai bien compris
Je l’ai pour le moment effectivement stoppé histoire qu’il n’y ait pas de “boulettes”.
Poka a créé un canal à ce sujet sur axiom team ça va permettre d’affiner.
Cesium ne stocke pas les identifiants sur chez un tiers de confiance, contrairement au service dont on parle, mais bon… C’est de bonne guerre !
Effectivement on dépend beaucoup de l’hébergeur, et de son honnêteté (non modification de code, etc)
G1Cotis a également une fonction de virements récurrents. La logique c’est :
l’hébergeur.e génère et possède les clefs privées. Chaque utilisateurice a un compte de « réserve » attribuée, où iel ne peut que déposer.
les virements périodiques de montant fixe sont envoyés automatiquement
Les utilisateurices remplissent leur réserve quand ça leur chante.
un courriel est envoyé automatiquement quand il reste moins de 2 paiements en réserve. Pas encore implémenté.
Ceci permet de séparer le moment des versements client du moment du paiement fournisseur, et a moins de contraintes de sécurité pour les utilisateurices.
Afin de réduire le risque qu’un utilisateur entre les ids d’un compte membre malgré l’avertissement, il pourrait y avoir un JS qui afficherait un avertissement supplémentaire si le compte donné est membre, avant de l’envoyer au serveur.
Avec le problème tout de même qu’un compte non membre aujourd’hui peut devenir membre demain… la solution de @matograine de gérer lui-même des comptes portefeuille qu’on peut remplir quand on veut me paraît plus sécurisée.
Il doit organiser les virements des ses clients. Il a du leur dire de ne pas utiliser leur compte membre.
C’est un outil qui a du potentiel effectivement, l’objectif n’était pas de le dénigré… Mais d’éviter qu’il soit diffusé “trop tot”