Pour tester: yunohost app upgrade wallabag2 -u https://github.com/lapineige/wallabag2_ynh/tree/testing
(comme d’habitude, faites une sauvegarde avant au cas où
We need some help to test the version 2.3.7
To test it : yunohost app upgrade wallabag2 -u https://github.com/lapineige/wallabag2_ynh/tree/testing
(as usual, do a backup before, just in case
Alors je n’ai pas tout testé mais ça semble fonctionner correctement.
J’ai pu faire l’upgrade.
Une sauvegarde a été faite durant l’upgrade.
Une fois upgradé j’ai pu ajouter et supprimer un article depuis l’application Wallabag Android.
Ce que je n’ai pas testé (entre autres) :
l’export et l’import des articles ;
l’ajout et la suppression d’un article depuis un navigateur. =>> Édit : ça fonctionne depuis un navigateur.
Wallabag will finally get fail2ban support, to protect you against brute force attacks
I need some help to test it. Can you try a fresh install, removal, backup, restore, and/or upgrade from last version ? yunohost app upgrade wallabag2 -u https://github.com/YunoHost-Apps/wallabag2_ynh/tree/fail2ban
Merci pour cette nouvelle testing
J’ai pu faire l’upgrade sans problème.
J’ai, depuis l’application mobile, pu ajouter un article, le prévisionner et le supprimer.
J’avais déjà remarqué des entrées fail2ban dans mon Logwatch il y a quelques temps.
Aujourd’hui, après quelques ajouts et suppressions d’articles, je me suis fait bannir de mon serveur après 5 essais depuis l’application Android. Je suis sur un VPS avec la dernière version stable de YunoHost sur une base Stretch.
Il faudrait voir si d’autres reproduisent le truc ou pas afin de voir si ça vient de YunoHost ou de l’application elle-même.
Pas de problème côté identifiants.
En fait il me semble qu’à chaque suppression d’un article l’action est exécutée et génère une entrée dans fail2ban.
Du coup avec les règles de fail2ban, au bout de 5 articles supprimés je suis banni du serveur pendant la durée paramétrée.
Il faudrait voir, si cette situation peut être reproduite, si ça vient de l’application en elle-même ou de son intégration dans YunoHost.
Ce qui m’étonne, c’est qu’en faisant la même chose, je n’ai pas de problème, et que personne n’ai signalé le problème. Si c’est une question de configuration de fail2ban dans Yunohost, j’imagine que ça aurait été remarqué par plus de monde
Tu n’a pas modifié la configuration de fail2ban je suppose ?
un bantime et findtime supérieurs à la configuration par défaut ;
une action plus complète en cas de bannissement (mwl) ;
une adresse mail spécifique et le sender aussi.
Je vais laisser Wallabag tranquille 24h et je verrai pour ajouter et supprimer un article depuis l’interface web pour voir si j’ai des entrées fail2ban dans Logwatch. Et du coup si c’estppropre à l’application Android ou pas.
Alors aucune entrée fail2ban dans mon Logwatch.
Je vais utiliser la panel web et non l’application Android, afin de voir si à l’ajout ou à la suppression j’ai des entrées fail2ban dans mon Logwatch.
Je vous tiens au courant
Il semble que le souci vienne de l’application Android.
Sauf erreur, les ajouts/suppressions faits via le panel web ne génèrent pas d’entrée fail2ban dans le rapport Logwatch.
Par contre, toujours sauf erreur, les ajouts/suppressions faits via l’application Android génèrent quant à eux des entrées fail2ban dans le rapport Logwatch.
Je vais voir pour désinstaller l’application Android, regarder dans le panel web s’il n’y a pas un truc à supprimer vis-à-vis de ça (autorisation, token, ID quelconque), la réinstaller et re-tester le truc.
De l’application, ou de l’usage de l’API
Faudrait que je re-regarde comment on a configuré fail2ban, pour voir si l’usage des logs de Wallabag n’aurait pas tendance à créer des alertes dans fail2ban…
Effectivement, peut-être voir du côté de la configuration de fail2ban, au-delà de l’identification, voir comment se comporte l’API à ce sujet car j’ai encore été banni en utilisant l’application.