Re: comment ignorer les cancels non authentifiés

Bonjour Stéphane,

Pour le problème spécifique au serveur de jdd, je viens de me rendre
compte que le cancel-lock basé sur l'utilisateur (au sens défini dans
readers.conf) est à adapter pour son cas.

[...]> Dans l'idéal, il faudrait que le futur INN 2.7 permette avec une simple

configuration de générer le cancel-lock d'après le posting-host en plus
de l'utilisateur. Je ne vois pas quel autre paramètre pourrait être utile
pour générer ce cancel-lock...

Je ne comprends pas bien le besoin de générer le Cancel-Lock depuis le posting-host.
Quel est le problème exactement avec la conf du serveur de Jean-Daniel ?
Pour vérifier un Cancel-Key, il n'y a besoin d'aucune information particulière si ce n'est le hash du Cancel-Lock initial (donc c'est indépendant des données qui ont servies à générer le Cancel-Lock).
Pour créer un Cancel-Lock, c'est une action locale à un serveur de news. INN 2.7.0 génère un Cancel-Lock pour l'administrateur (pour qu'il ait la main pour annuler l'article si besoin) et l'utilisateur (en se basant sur son identifiant). Les autres serveurs se moquent de la clé initiale utilisée. Quand ils recevront un Cancel-Key, celui-ci aura été calculé par la même implémentation logicielle qui a créé le Cancel-Lock (donc la clé initiale est cohérente).
--
Julien ÉLIE
« Don't marry for money; you can borrow it cheaper. » (proverbe
   écossais)