Parametring cancel processing (Cancel-Lock vs unauthenticated cancels)

Julien ÉLIE julien at trigofacile.com
Sun Jan 2 22:00:24 UTC 2022


Hi Russ,

>> 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 like this idea.  I'd default to "none" otherwise (may as well be more
> secure by default, and we're allowed to break some compatibility in the
> 2.7.0 release).

OK, let's the default be the most secure ("none").


>> I also suggest removing the "innd -C" flag, or rather make it a no-op,
>> as the "docancels" parameter does the same thing, better.
> 
> I think it shouldn't be a no-op; it should either work to override the
> config setting or we should remove it so that it will cause an error and
> people will have to update their configuration.  Otherwise, I think we
> risk silent and surprising behavior change.

I thought of writing a notice log line for the no-op, but you're right 
that it may not be seen by the news admin.  Overriding the config 
setting would add complexity in the (already complex) documentation and 
configuration, so I'll just remove the "-C" flag then.  Easy to fix with 
a meaningful error log if a news admin uses that flag and updates INN to 
INN 2.7.0.
Besides, if we keep "-C", a news admin may not notice that he disabled 
authenticated cancels whereas he would have wanted them.

-- 
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