Feature Proposal: Add a plugins handler for registration validation
It's clear from the hassle we've had dealing with scumbag spammers today that the handler architecture is inadequate. There is an existing all-but-useless registrationHandler that is only called after
the registration is nearly complete, forcing the callee to manually remove the registration. An earlier handler could audit the registration and veto it.
Description and Documentation
Allows a plugin to validate that the $data represents an allowable registration. The handler should raise an exception if it wants to veto the registration, in which case the user will not be registered.
The reason for a handler rather than a pluggable module is that the handler can potentially modify fields in the registration record - for example, add new fields or modify existing fields (such as lower-casing login names). However the plugin author will have to be ultra-careful, as there will be no additional validation of their changes.
The plugin handler needs to be invoked as a final step in
, which already performs several validation steps.
I believe that this important enough that it needs to be moved to an accepted state ASAP. So I suggest we drive for a "ConsensusReached" state, and include it in 1.2.0 so that AntiWikiSpamPlugin
can utilise it. I think "consensus" will have been reached when at least the following people have indicated approval of the plan:
-- Contributors: CrawfordCurrie
- 14 Mar 2012
Definitely! We need this ASAP. I've tweaked the
modules a bit for 1.1.5, so that any exception thrown during the validation will no longer leave partially registered addresses. I've tested it with AntiWikiSpamPlugin
, and any regex matches in Meta when the User Topic is saved will kill the registration and no longer leaves partially registered users. But data outside of the user topic, like email address is missed. And the existing handler is too late. It's defined for use "post Registration"
So my only question is should this be a plugin handler, that adds some (small?) overhead to every transaction, or a pluggable module that registration calls. I don't object to the handler - just raising a question. It's more important to get it.
And to me given the mess this week on Foswiki.org, I'd even like to see this sneak into 1.1.5, even if we don't document it but have it for "evaluation" for effectiveness.
- 14 Mar 2012
Sounds good. We'd use it.
- 15 Mar 2012
Also need to deprecate the registrationHandler, which AFAICT no-one has ever called. The original purpose for this handler was blown away by the user mappers, and it has never done anything useful anyway.
- 15 Mar 2012
No feedback from MichaelDaum
, though I know he is aware of the proposal. So marking this as accepted by consensus, and implementing it.
- 21 Mar 2012