Re: Parametring cancel processing (Cancel-Lock vs unauthenticated cancels)

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. »
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers