Galette

Pour info, je compte utiliser fail2ban pour surveiller tout ca, et je confirme, c'est plus direct et uniforme de suivre des logs en fichiers (ou assimilés). Par exemple fail2ban peut repérer également les attaques SSH, tentatives de pollution DNS et bien d'autres. C'est utile d'avoir de l'uniformité à ce niveau quand on a des services très divers à surveiller.

Merci pour les infos sur les versions, effectivement ce qui compte pour moi c'est d'avoir le moins possible à maintenir mes propres patches, donc si la prochaine version est a priori la 0.9, ça va très bien. Je vais voir pour tester en branche 'develop', et te tiendrai au courant.

Pour l'IP enregistrée dans historique, si l'on parle bien de la colonne ip_log de la table galette_logs, effectivement je vois uniformément l'adresse du reverse proxy depuis qu'on en a un… Je peux ajouter des patches pour ça, mais il y a un petit hic dans le cas le plus genéral : X-Forwarded-For est multivalué (représente la chaîne entière de proxies), et si l'on fait confiance aveuglément en prenant la première valeur, alors c'est facile de tricher, ou simplement c'est sans intérêt (par exemple avec une adresse privée comme point de départ, et un forward-proxy, scénario courant de réseau d'entreprise ou de hotspot). Donc il faudrait un param de config indiquant quel(s) proxies on veut remplacer par l'IP amont, ça devient plus compliqué, mais je veux bien le faire.

Georges Racinet a écrit :

Merci pour les infos sur les versions, effectivement ce qui compte pour moi c'est d'avoir le moins possible à maintenir mes propres patches, donc si la prochaine version est a priori la 0.9, ça va très bien. Je vais voir pour tester en branche 'develop', et te tiendrai au courant.

Ok, merci :)

Pour l'IP enregistrée dans historique, si l'on parle bien de la colonne ip_log de la table galette_logs, effectivement je vois uniformément l'adresse du reverse proxy depuis qu'on en a un… Je peux ajouter des patches pour ça, mais il y a un petit hic dans le cas le plus genéral : X-Forwarded-For est multivalué (représente la chaîne entière de proxies), et si l'on fait confiance aveuglément en prenant la première valeur, alors c'est facile de tricher, ou simplement c'est sans intérêt (par exemple avec une adresse privée comme point de départ, et un forward-proxy, scénario courant de réseau d'entreprise ou de hotspot). Donc il faudrait un param de config indiquant quel(s) proxies on veut remplacer par l'IP amont, ça devient plus compliqué, mais je veux bien le faire.

Hum... Je ne pensais pas que la récupération serait si "compliquée" :-/ je te laisse juge pour le coup ; tu es actuellement le seul utilisateur ayant émis ce type de besoin.
J'ai créé un ticket à part (#1031) pour ce point précis, sachant que je ne pourrai m'en charger moi même, si tu es partant... :-)

Je confirme que le patch pour la branche develop fonctionne :

192.168.0.202 - 2017-05-27 14:43:39 - 4 - No entry found for login `asd` Client 192.168.0.245 X-Forwarded-For 2a01:e35:abcd:dead:beef:abcd:6385:b204

Vu pour #1031, merci, et pour ce qui est de la complexité, bah c'est l'adresse IP elle même qui n'est qu'un pis-aller.

Super, merci !