> Fuelled by some of the recent discussions, I think the whitelisting > concept needs to be re-thought. i agree
> My idea would be that there are only two things that can be whitelisted: > connections and transactions. On the base of what logic, and at what > stage, is up to the plugin, but if the whitelist flag is set, any DENY* > return value from subsequent plugins' hooks should be treated as DECLINED. The real question is what does whitelisting mean? This is one thing it can mean. It could also mean that a plugin MUST return DECLINED when the whitelist flag is set. Your case allows for OK. My case does not. (I kinda like yours better). > Maybe, for the sake of efficiency, we could think of a mechanism for > some plugins that only to checking (no logging and no queuing) to be > bypassed altogether when whitelisting is in effect. The problem seems to be that whitelisting means different things to different plugins. I started thinking of creating a whitelisting subsystem where each plugin could share in a global whitelist or have one of it's own. If we can narrow the definition, scope, and effects of 'whitelisting' it may then be possible to implement something that all/most plugins could use. -- JT Moree
