Parametring cancel processing (Cancel-Lock vs unauthenticated cancels)
Julien ÉLIE
julien at trigofacile.com
Sun Jan 2 21:28:51 UTC 2022
Hi Martin,
> from an admins perspective there are four possible polices regarding
> cancels:
>
> 1. Execute all cancels, don't check Cancel-Lock. (the default now)
> 2. Execute no cancels. (with "-C" flag)
> 3. If the original article is protected by Cancel-Lock, check Cancel-Key
> and execute the cancel if it authenticates. If it is not protected by
> Cancel-Lock execute in any case.
> 4. If the original article is protected by Cancel-Lock, check Cancel-Key
> and execute the cancel if it authenticates. If it is not protected by
> Cancel-Lock, do not execute.
>
> With your idea all four could be achieved without recompiling:
>
> 1: canlockcheck=false
> 2: -C, canlockcheck=false
> 3: canlockcheck=true
> 4: -C, canlockcheck=true
>
> Wich would make 3 the new default, which is also a good idea.
Yes, exactly.
> But having to configure it in two places and think this through is not
> so easy. What about a new parameter, eg. "docancels" with the options
> "all", "none", "auth" and "require-auth"?
I like this idea. I suggest that the default be "require-auth" (4) if
INN was built with Cancel-Lock support, and "all" (1) otherwise.
Or maybe "none" (2) otherwise? We can do that change in the upcoming
major 2.7.0 release.
I also suggest removing the "innd -C" flag, or rather make it a no-op,
as the "docancels" parameter does the same thing, better.
--
Julien ÉLIE
« C'est une forêt vierge où la main de l'homme n'a jamais mis le pied. »
More information about the inn-workers
mailing list