Ajouter un support "cachage d'articles par utilisateur" à INN (was: Re: Remarques au sujet des données du PROXY)

[Marc SCHAEFER]

[ Followup-To: fr.comp.usenet.serveurs ]

Gilbert OLIVIER <gilbert...@orange.fr.invalid> wrote:
> cet état pour MacCafé, et au final il semblerait que mon signalement
> t'ai fait découvrir un "véritable" bug ;-)

Oui, merci: et il y en a plein encore à trouver :)

En fait, idéalement, des fonctions de filtrage basées sur un script Perl
directement appelé depuis INN2, qui permettraient en tout temps de
modifier ce que voit chaque utilisateur, serait super-utile dans une
future version d'INN2.

Ca me permettrait de remiser mon proxy!

Exemple: à chaque LISTGROUP, (X)OVER, ARTICLE, HEAD, BODY, NEXT, LAST,
INN appelerait une fonction Perl du genre, pour chaque Message-ID:

sub hide_article {
my ($msgid, $user) = @_;

# traitement sur $msgid, p.ex. consultation d'une base
# de données de message à filtrer pour $user

return 1; # si on veut cacher cet article pour cet utilisateur
}

Ca ne me semble pas forcément ralentir trop INN, d'autant plus si
le code Perl utilise son propre cache interne.

[Marc SCHAEFER]

In fr.comp.usenet.serveurs Marc SCHAEFER <scha...@alphanet.ch> wrote:
> En fait, idéalement, des fonctions de filtrage basées sur un script Perl
> directement appelé depuis INN2, qui permettraient en tout temps de
> modifier ce que voit chaque utilisateur, serait super-utile dans une
> future version d'INN2.

Un autre souhait dans nnrpd serait la possibilité d'ajouter "on the fly" des
entêtes.

Exemple le fameux X-NoCeM (quand l'utilisateur n'a pas activé un filtre
mais souhaite le gérer sur son client): (attention, contenu vulgaire):

https://nnrp.alphanet.ch/newsgroup/fr.usenet.abus.d/%3Ctgf271%241lbd%241%40gioia.aioe.org%3E?mode=raw

X-NoCeM: noce...@alphanet.ch/injures, ro...@pasdenom.info/spam4

[jdd]

connais-tu "postfilter"

http://www.dodin.org/wiki/pmwiki.php?n=Doc.INNFiltering#toc-2

je crois qu'il fait tout ce que tu veux et plus encore, mais c'est
délicat à configurer

jdd
--
mon serveur dodin.fr.nf

[Marc SCHAEFER]

jdd <j...@dodin.org> wrote:
> connais-tu "postfilter"

Je doute qu'il puisse cacher des articles par utilisateur ou modifier in
extremis un article au moment de l'envoyer à l'utilisateur.

> http://www.dodin.org/wiki/pmwiki.php?n=Doc.INNFiltering#toc-2

A ma connaissance, et après avoir lu ta doc, c'est un outil qui bloque
les spams au moment des posts par l'utilisateur, non? Ou qui peut
ajouter des entêtes au moment du post, mais ce n'est pas ce que je veux
faire.

[jdd]

je ne suis pas sur d'avoir tout compris de postfiltern mais il identifie
les utilisateurs, même non authentifiés et peut modifier les en-têtes.

il n'agit que sur les posts émis depuis ton serveur

[Marc SCHAEFER]

jdd <j...@dodin.org> wrote:
> je ne suis pas sur d'avoir tout compris de postfiltern mais il identifie
> les utilisateurs, même non authentifiés et peut modifier les en-têtes.
>
> il n'agit que sur les posts émis depuis ton serveur

Oui, j'ai effectivement écrit du code dans filter_nnrpd.pl qui

a) modifie les articles postés par mes utilisateurs
(p.ex. modification du champ identifiant l'adresse IP,
ou ajout de Cancel-Lock)

b) refuse certains articles selon des critères (p.ex.
nombre de lignes de citation).

Postfilter a l'air de faire ça, et plein d'autres choses, en particulier
lorsqu'on a renoncé à authentifier ses utilisateurs (ce qui n'est pas
mon cas).

Mais cela n'a rien à voir avec mes 2 demandes concernant INN.

Donc, je rappelle ce que fait mon proxy:

1) il ajoute à tous les messages un entête X-NoCeM listant les NoCeM où
figure le Message-ID du message, ce qui permet à un utilisateur
d'activer ses propres filtres dans son logiciel de news.

TOUS les messages consultés par l'utilisateur, pas les messages
postés par l'utilisateurs!

2) il cache les articles figurant dans les NoCeM activés par l'utilisateur
via l'interface web.

rien à voir avec une interdiction de post basé sur des critères!

Ma demande était: si c'était implémenté dans INN (comme p.ex. le fait
qu'INN 7 va supporter directement les Cancel-Lock en interne), ça serait
mieux qu'un proxy comme le mien.

Ma suggestion: ajouter deux "hook" Perl à INN qui permettent, dans
nnrpd:

- de modifier un article juste avant de le remettre à l'utilisateur

- d'indiquer quels articles doivent être cachés à l'utilisateur

Ainsi tu pourrais, facilement et sans installer mon proxy (ce qui est
assez compliqué), implémenter du cachage d'article configurable par
l'utilisateur comme je le fais depuis quelques mois.

[Julien ÉLIE]

Bonsoir Marc,

> Ma suggestion: ajouter deux "hook" Perl à INN qui permettent, dans
> nnrpd:
>
> - de modifier un article juste avant de le remettre à l'utilisateur
>
> - d'indiquer quels articles doivent être cachés à l'utilisateur
>
> Ainsi tu pourrais, facilement et sans installer mon proxy (ce qui est
> assez compliqué), implémenter du cachage d'article configurable par
> l'utilisateur comme je le fais depuis quelques mois.

Je comprends bien la demande. J'attire toutefois l'attention qu'une fois
l'article injecté, il n'est pas censé être modifié... Pas d'ajout
d'en-tête, y compris sur le "dernier" serveur :

Serving agents MUST NOT alter, delete, or rearrange any part of an
article except for the Path and Xref header fields.


On avait eu la discussion déjà lorsque tu avais proposé diverses
possibilités d'implémenter ton proxy.
Vu que ce n'est pas standard, je ne suis personnellement pas tellement
chaud pour l'intégrer à INN. (Quelqu'un d'autre pourrait bien sûr avoir
un avis différent.)

Pour le fait de cacher des articles, hmm pourquoi pas mais ça demande
pas mal de travail pour réaliser la fonctionnalité proprement dans
toutes les requêtes NNTP...

--
Julien ÉLIE

« Un vol en rase-bottes, quoi ! » (Astérix)

[Marc SCHAEFER]

Julien ÉLIE <iul...@nom-de-mon-site.com.invalid> wrote:
> Pour le fait de cacher des articles, hmm pourquoi pas mais ça demande
> pas mal de travail pour réaliser la fonctionnalité proprement dans
> toutes les requêtes NNTP...

Cette fonction est nécessaire pour permettre toute la liberté que les
NoCeM permettaient, vu que les agents ne l'implémentent pas.

Mais bon, mon proxy marche pour moi :)