Re: Cancel-Key et Cancel-Lock ne fonctionnent pas sur dodin.fr.nf

Salut Stéphane,

Et il me semble que tu avais écrit que sur la version 2.7, INN ne
générera au mieux* qu'un CL-admin si l'utilisateur est anonymous.

Oui c'est ce que je prévoyais lors de la conception détaillée initiale, mais j'ai au final aussi implémenté la possibilité de choisir d'utiliser l'IP pour un groupe d'accès "anonyme" car je me doutais bien qu'il y aurait de la demande :-)
   https://www.eyrie.org/~eagle/software/inn/docs/readers.conf.html
"""
addcanlockuser:
If set to none, posts made by these users will not have a user-specific hash in the Cancel-Lock header field (only the admin hash will be generated).  No Cancel-Key header field will be present in cancel or supersede requests.  This is a string value and the default is "username", that is to say a user-specific hash based on the identity assigned to the connection is used.
Another possible value to this parameter is "ip", in which case a user-specific hash based on the IP of the connection is used (which should be a static IP so as to actually identify users).
See inn-secrets.conf(5) <https://www.eyrie.org/~eagle/software/inn/docs/inn-secrets.conf.html> for more information about Cancel-Lock.  The main reason for this parameter is to deactivate this authentication mechanism when the same identity or IP can be assigned by an access group to different people. Otherwise, any of these people would be able to send an authenticated withdrawal of an article originally sent by another person with the same identity or IP.
"""
Avec quelques exemples, comme le fameux accès anonyme :
     auth default {
         hosts: *
         default: <PUBLIC>
     }
     access default {
         users: <PUBLIC>
         newsgroups: example.*
         addcanlockuser: none
     }
Ou encore :
Here's an example of another common case: a server that only allows connections from a local domain and has an additional hierarchy that's password-restricted.
     auth "example.com" {
         hosts: "*.example.com"
         auth: "ckpasswd -f <pathdb in inn.conf>/newsusers"
         default: "anonymous"
     }
     access regular {
         newsgroups: "*,!example.restricted.*"
         addcanlockuser: none
     }
     access full {
         users: "*,!anonymous"
         newsgroups: *
     }
Ce niveau de configuration offre pas mal de flexibilité :-)

J'avais écrit à jdd sur son serveur sur un groupe interne qu'il y a 3
solutions. Je viens d'en voir une quatrième : proposer à ceux qui le
veulent de s'authentifier, c'est probablement possible dans readers.conf
mais, je ne saurais dire comment...

Ah ben justement, l'exemple précédent correspond à ce cas d'usage (tu mets un "auth" et un "default" (anonyme) dans le bloc d'authentification).
--
Julien ÉLIE
« La moitié des hommes politiques sont des bons à rien. Les autres sont
   prêts à tout. » (Coluche)