8 Dec 2011 23:00
Re: Can I block people from creating accounts if they don't verify their address?
Paul Boddie <paul <at> boddie.org.uk>
2011-12-08 22:00:24 GMT
2011-12-08 22:00:24 GMT
On Thursday 08 December 2011 16:05:31 Steven W. Orr wrote: > > This is not really what I want. I don't want other people to not be allowed > to create accounts. What I want is to prevent people from creating accounts > whose email address matches a pattern. In my case (today) the interlopers > are all on the .info TLD Are they all providing .info e-mail addresses or are their requests originating from addresses resolving to .info domains? It seems to me that spammers could easily work around restrictions on e-mail addresses. Nevertheless, you could just change the newaccount action to check the e-mail address. Something like this, after checking for the address's presence for an existing user and just before saving the new user... blocked_pattern = getattr(request.cfg, "blocked_email_addresses") if blocked_pattern: blocked_regexp = re.compile(blocked_pattern) if blocked_regexp.match(theuser.email): return _("Couldn't register you!") Feel free to use this, play around with it, use multiple patterns or whatever. I guess you'd set the pattern up like this: blocked_email_addresses = r".*?\.info$" You could use the | operator and brackets to add more possibilities. > Another thing that would be wonderful would be if the account creation > could be completed only by responding to a confirmation email, the same as > if you were signing up for a mailing list. I saw the following e-mail confirmation patch when searching the Moin site for "account creation": http://moinmo.in/RussellStuart/EmailActivation The discussion is a bit weird because a lot of the timestamps give the current time instead of the time of each message, but it seems that people have been looking at this code and the problem in general fairly recently. > But, I don't want to disallow everyone from signing up as a default. > > BTW, I should mention that all of the spam that I'm getting is not only > coming from the .info TLD, it's also coming in despite TextCha being > enabled. That never used to be the case. It's possible that determined people could target a site using TextCha and defeat it, but that goes somewhat beyond what TextCha is designed to handle. With regard to general frameworks around the mechanisms discussed here, the new account action doesn't seem to utilise any event mechanisms that you find elsewhere in Moin, so you can't write a plug-in that performs a post-registration check. I experimented with an event handler that performs authorisation checks on edits: http://moinmo.in/ActionMarket/ApproveChanges This is a potentially large sledgehammer to crack the nut of spam, however, but it effectively queues all edits from anyone you haven't explicitly nominated as being trustworthy. Spammers shouldn't see any of their edits published unless you approve them. Paul ------------------------------------------------------------------------------ Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/