Feature Proposal: Add a plugins handler for registration validation

Motivation

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

=begin TML
---+ validateRegistrationHandler($data)
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.
=cut

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.

Implementation

The plugin handler needs to be invoked as a final step in Foswiki::UI::Register::_validateRegistration, 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

Discussion

Definitely! We need this ASAP. I've tweaked the UI::Register and TopicUserMapping 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.

-- GeorgeClark - 14 Mar 2012

Sounds good. We'd use it.

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

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

-- CrawfordCurrie - 21 Mar 2012
I Attachment Action Size Date Who Comment
regval.difdif regval.dif manage 5 K 15 Mar 2012 - 14:37 CrawfordCurrie Patch to implement the handler under discussion
Topic revision: r9 - 05 Jul 2015, GeorgeClark
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy