On 2012-06-13 03:43, Phil Pennock wrote:
> On 2012-06-12 at 19:54 +0100, Jeremy Harris wrote:
>>> If the ACL returns non-accept, does that cause an immediate expansion
>>> failure? Does it count as a forced failure?
>>
>> I've made it cause a failure, but I'm not sure of what type....
>> It's in expand_string_internal() like the notdef
>> case of EITEM_DLFUNC.
>
> That's non-forced.
[...]
> I take it
> that a defer return which sets message will expand successfully to that
> message?
Currently, no. I have
accept - OK - expansion from message
defer - DEFER - empty expansion
deny - FAIL - non-forced fail
oops - ERROR - non-forced fail
It seems reasonable to change FAIL to be a forced failure,
but then we can't use accept vs. deny as the obvious true vs. false
if we want to have a direct boolean result (as an expansion condition).
Modifying ERROR to be anything but a (non-forced) fail doesn't seem
right.
>
> Should this instead be an expansion condition with a side-effect of
> setting $value in both the true and false branches?
I did wonder about that. It would make use in a foreach/forany/filter
possibly neater. Though - OK give true seems fine, but what to give
false?
I'll have to look what it would do to reduce
(the doc doesn't say what happens on a forced-fail for string3).
>
>
> ACLs can return: OK DEFER FAIL ERROR.
>
> The OK case is easy, we'll ignore that and just consider the other
> three.
>
> By my reckoning, ERROR is the only one of the three which should not
> count as a forced failure, if they map to expansion failure. Whether
> they do or not presumably depends upon whether or not message was set?
I'd not considered using message in that way.
>
> IF either DEFER or FAIL can result in expansion failure, then for those
> two ACL return codes, the expansion operator should set
> expand_string_forcedfail so that it becomes "fails by policy", rather
> than "fails by misconfiguration".
>
> (Why yes, we are using one word for two different meanings and just
> tacking on "forced" to distinguish between them)
How about:
accept - OK - true + message
defer - DEFER - forced fail
deny - FAIL - false + message
oops - ERROR - non-forced fail
(though I don't see any way of using the string result *and* the
boolean result from a single call at present, one might happen in the future)
--
Cheers,
Jeremy
