Salut, plutôt que de passer du temps à rejeter les comptes spam à la main sur git.spip on pourrait simplement les ignorer et laisser un cron les supprimer au bout d’un certain temps. C’est possible en activant la conf suivante Moderate users (administration) | GitLab dont il faut juste définir le délai.
Ça vous va ? C’est possible de faire ça @ben ?
ça devrait pas être posté ici :
spip/*
à défaut, ça pourrait être dans la catégorie « dev », sinon, on créé une catégorie admin-git ?
et pour répondre, hélas, je crois qu’il faut une instance premium (payante) pour ce type de paramétrage (on est en « free »)
Mince, alors on fera le ménage à la main de temps en temps :\
Sinon faut remettre le système qu’on avait avec Gitea avec la demande via Contrib…
Je trouve que ce mécanisme est plutôt contre-productif. Ça ne change rien aux problèmes auxquels nous faisons face. Il ne fait que déplacer le problème vers un autre système nécessitant de la modération et donc du temps « humain ». Que ce soit en terme de maintenance et de réglages du code que cela exigerait, tout cela sans changer le principe : vérifier des demandes d’inscription, s’en remettre à un jugement individuel et subjectif, valider, etc.
J’estime que ça ne va pas aider et pire, mobiliser de l’énergie supplémentaire pour un résultat, au mieux, équivalent.
Franchement, on peut faire mieux.
Même avis pour la « charge technique » que ça engendre et surtout ça rend plus complexe l’inscription des nouvelles personnes qui souhaitent contribuer (j’ai encore souvenir de pas mal de demandes d’aiguillage quand l’inscription se faisait sur contrib).
Les deux avantages que ça avait c’est que
Là en restant sur la forge, est-ce qu’il y a des moyens de 1) avoir une technique d’anti-spam pour freiner déjà un max de robot dessus ? (plus qu’actuellement), et 2) permettre un champ libre de « raison » que les modérateurs peuvent lire ensuite ?
Ça change tout parce que là on reçoit une avalanche de mails inutiles alors qu’avant je recevais un mail de temps en temps étant donné qu’on demandait une explication. Donc c’était plus efficace (statistiquement j’avais plus de 50% de spams).
Le temps humain je ne vois pas ce qui gêne car c’est moi qui l’ait assumé pendant ces années (comme les catégories des plugins, le rangement des plugins dans contrib, etc.) et de ce que j’ai compris aujourd’hui nous n’avons pas les moyens de faire autrement : donc où est l’amélioration ?
Concernant le jugement, il est certainement moins subjectif de se baser sur une demande écrite humainement que sur une adresse mail.
Je peux comprendre que tu ne soit pas favorable à la solution qui était en place, pas de souci, mais de là à utiliser des arguments douteux c’est chiant.
Par contre, ça montre un certain manque d’empathie pour les esprits limités qui ont fait des choses moyennes en leur temps…
Je ne crois pas, mais à ce jour on est réglé en mode hard pour la confirmation des emails lors de l’inscription cf pour Sign-up restrictions | GitLab ; ce qui veut dire que les comptes à spam ne sont pas activés (je n’ai pas encore vu de spammer confirmer son mail). On peut aussi filtrer les domaines des mails avec une liste d’autorisation ou d’exclusion, mais ça ne me semble pas une bonne piste.
PS : il n’y a pas que le mail pour repérer un spam, il y a aussi le username.
Bref, je pense qu’on peut simplement laisser couler en ignorant les comptes à spam et en faisant le ménage à la main tous les 6 mois pour virer tous les comptes non confirmés.
On en finirait jamais avec ce genre de solution … faudrait que quelqu’un mette à jour la liste …
+1, d’autant que ça peut s’automatiser très facilement malgré tout.
« avalanche », c’est un peu exagéré, je trouve.
Il suffit de ne plus être admin du serveur pour éviter ça. Cf Désactiver les notifications email "Gitlab account request"
Pour info, on n’est pas les seules personnes à avoir ce genre de problème, exemple chez freedesktop Reduce user account spam (#600) · Issues · freedesktop.org / freedesktop · GitLab dont l’équipe a mis en place un robot freedesktop.org / damspam · GitLab et des règles strictes Spam · Wiki · freedesktop.org / freedesktop · GitLab
Et pour rappel, on a déjà activé la fonction Invisible Captcha qui ajoute un champ masqué au form d’inscription pour repérer les bots.
Deux outils simples proposé par Luc de chez Frama :
remove_users.sh will remove the accounts that never connected in 10 days (put it in a daily cron task).Ça me semble être de bonnes pistes.
J’ai en local une moulinette qui rejette les demandes d’inscription non-approuvées au bout de 48 heures. Elle marche bien. Je la lance quotidiennement depuis… hier 
. Y a moyen de la mettre en place avec un cron sur une machine, c’est pas très groumand 
Super, faudrait qu’on en cause en live avant de proposer de poser ça sur le serveur en cron.