New Foswiki release 2.1.6 is available with important security fixes.
Sourceforge foswiki email lists being discontinued. Subscribe to the new Foswiki announce and discuss lists at MailingLists
You are here: Foswiki>Tasks Web>Item710 (11 Apr 2012, GeorgeClark)Edit Attach

Item710: Registration failure due to email created topics but loses the password (deferred to 1.1)

Priority: Normal
Current State: Closed
Released In: 1.1.5
Target Release: patch
Applies To: Engine
Component: FoswikiUIRegister
Branches: Release01x01 trunk
Reported By: SvenDowideit
Waiting For:
Last Change By: GeorgeClark
When you register but email fails, Foswiki thanks the user for registering, makes the topics, and tells them it failed to send the confirmation email. Unfortuanatly, this stops the username and password from being stored in the htpasswd file. The admin then needs to find an email address to talk to the user, confirm who it is, then change it and reset the pwd.

-- SvenDowideit - 09 Jan 2009

This issue is mainly a problem that occurs when Foswiki has just been installed and the email feature has not been setup correctly

Once the site is up running normally you do not see this on a daily basis.

For the initial installer this is what you need to do when you have this problem.

First you need to fix the email problem so emails get sent correctly.

Typical root cause is that the local maill agent program like sendmail is not running as daemon.

Once you are there - you need to check that the user that is already registered gets a new password. Using the reset password feature is one way. The other is to delete the users home topic and the line in WikiUsers and let him register again.

-- KennethLavrsen - 09 Jan 2009

In fact what happens is that the user topics and htpasswd record are created, but then if sending email fails, the htpasswd record is removed. The comment next to this code says: Email address doesn't work, likely fraudulent registration.

There are conflicting requirements here; "don't create the user unless every part of registration succeeds" versus "keep info around so hat registration can be completed once the problem is fixed".

I tend to the view that registration should be aborted (no user records of any kind created) unless all registration conditions are met. However I don't subscribe to the notion that sending a registration confirmation is a condition for a successful registration. Are there any circumstances under which registration depends on being able to send that mail? e.g. auto-generated password?

As Kenneth has highlighted there is a workaround for this so it's not really Urgent, but I'm leaving the priority high for now to keep it on the radar.

-- CrawfordCurrie - 23 Jan 2009

The only time where the registration requires confirmation. If the user never gets his email he never gets his confirmation code. This is the case where the registration failure is annoying.

It is only when confirmation is required this is a real issue. When it is not needed the registration should complete even if the sending email fails.

-- KennethLavrsen - 26 Jan 2009

A well configured Foswiki works fine and the issue will normally be found by the person installing when he tries to register. So I will release 1.0.1 with this open.

Keeping it urgent so it stays on the radar.

-- KennethLavrsen - 07 Feb 2009

Actually, I'm responsible for the "fraudulent registration" comment.

This is arguably a policy issue - but here's mine:

The fact that the email doesn't get sent is more than an annoyance. It indicates that the organization responsible for the wiki has no way to contact this person.

If someone registers without a valid e-mail address, one can not contact that individual. That means that the individual can not be held accountable for what's placed on the wiki. The form asked for the e-mail twice - so it's probably not a typo. Which is why I suspect fraud - someone trying to get write permission without revealing their identity. Since registration has been enabled, this seems like a really bad idea.

I actually believe that in this case, the full registration should be rolled-back. But that requires remove_user to work in several places where it currently doesn't.

It is true that someone can register with a throw-away e-mail address, deleting it after registration succeeds. That's the subject of another site policy - those of us who care can periodically validate that all registered e-mail addresses are still valid.

It's also true that not all invalid e-mail addresses will fail at this point. But this check is better than ignoring the failure; it blocks a considerable number of abuse cases.

If there is a really strong lobby for allowing registration without requiring a valid e-mail address, I suppose we could have a configuration variable like {ValidEmailRequiredToRegister}. This implies requiring confirmation...

-- TimotheLitt - 11 Feb 2009

I have boxes with no mail configuration at all: no local sendmail, no smtp host configured. On those boxes I (the admin) create a handfull of logins manually using the standard UserRegistration way.

Invalid or at least non-existing mail configs should be tolerated by Foswiki.

-- OliverKrueger - 08 Apr 2009

Although more complicated, it is probably better to differentiate between MTA being down, which is a site or network error, and recipient not found, bounces, etc. which are more likely due to fraudulent reservations. When using a local MTA like postfix, how does this block fraudulent registrations? The MTA queues the bad message, foswiki is happy and completes, and the message bounces. Unless we have a bounce processor, I don't understand the benefit of leaving a half-registration.

-- GeorgeClark - 19 Apr 2009

You can only do this if you are 100% the MTA is queing the messages. How do you know this when you install Foswiki? The MTA can be remote with an ISP (mine is) and you can have misspelled the URL or not put the right authentication.

If the registration completes and verification is required the registration must never start unless the MTA is alive and working.

Otherwise people register and never ever get the mail with the vital confirmation code. And then we have got nowhere.

In my view we should implement a sort of ping to the MTA that queries if it is alive IF verification is enabled BEFORE any other registration steps are performed. If the MTA is not alive we must abort with a message in the browser saying that registration is disabled because the mail server is not working. This way the admin installing gets a useful message. And users trying to register can come back later and if still failing notify the admin by email.

The next step after pinging the MTA should be sending the email. And if that fails abort again. MTA can be up but SMTP authentication which is common now to prevent spam failing.

Once email is sent we can create the user topic, add the user to the password file and to the WikiUsers topic.

Big change which I defer to 1.1

-- KennethLavrsen - 19 Apr 2009

One more thing that could possibly be done - check the domain of the email address to determine if the the domain has a MX record and can accept email. That would at least block bogus domains. It's typically not possible any more to actually check if the actual user address is valid - most servers won't But the domain check can be done. See Email::Valid Might have to be cautious about impact of DNS timeouts.

-- GeorgeClark - 20 Apr 2009

As Timothe observes, this is a policy question. At the moment we have a configuration option "requires confirmation". This is effectively a confirmation of the email address that the user registered with. If an error occurs when sending the email, that leaves an incomplete registration which can block further registrations using the same information. This is very different to the scenario where a confirmation mail is sent, but is never recieved or never responded to. However this latter scenario is another case where a partial registration needs to be rolled back; for example, if the registration isn't completed within 7 days.

I agree with Timothe that if that registration email cannot be sent due to an error, the only option is to roll back the whole registration. I think pinging the MTA is a complexity too far. However I also agree with Kenneth that this can be worked around, and as such is not Urgent, so I'm lowering the priority to Normal.

-- CrawfordCurrie - 16 Nov 2009

I think I have a fix for this for 1.1.5. has been changed to catch any errors thrown during the registration process and call the mapper function removeUser for the user being registered. This is a partial fix.
  • The user is removed from the WikiUsers mapping table.
  • The user is removed from the .htpasswd store.

If the user topic has been saved, it is not removed. But with the mappings and .htpasswd in a consistent state, it's a simple matter for the admin to delete the topic. As was pointed out this type of failure typically only occurs when the server is misconfigured.

I don't see this as actual spam registration control. The only way I've managed to get a failure is to mis-configure the SMTP configuration As long as sendmail or Net::SMTP is functional, then spam registrations from bogus domains (NXDOMAIN) or bad user in a valid domain still get registered.

-- GeorgeClark - 03 Mar 2012

ItemTemplate edit

Summary Registration failure due to email created topics but loses the password (deferred to 1.1)
ReportedBy SvenDowideit
Codebase 1.1.4, 1.1.3, 1.1.2, 1.1.1, 1.1.0, 1.0.10, 1.0.0, trunk
SVN Range
AppliesTo Engine
Component FoswikiUIRegister
Priority Normal
CurrentState Closed
Checkins distro:facec089504d distro:286f3dabe43b distro:bc6c66e15e81 distro:ec6da40cb4b7
TargetRelease patch
ReleasedIn 1.1.5
CheckinsOnBranches Release01x01 trunk
trunkCheckins distro:facec089504d distro:bc6c66e15e81
Release01x01Checkins distro:286f3dabe43b distro:ec6da40cb4b7
Topic revision: r30 - 11 Apr 2012, GeorgeClark - This page was cached on 11 Jul 2018 - 05:26.

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