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