Wikimedia Bugzilla is closed!

*** Bug 867 has been marked as a duplicate of this bug. ***

The proposed scheme will be introduced first and implemented in Enotif 2.00 for
CVS, scheduled publication date 30.11.2004

It works reasonable and is easy to implement using mostly the existing code-lets:

Let me shortly explain what I have implemented:

If a user changes the password (which can now also be done directly with the
form on the login-screen), he or she will be forced to one dummy cycle with a
temporary password. However, there is one significant difference to the "I
forgot my password" cycle: the user *must* re-visit the wiki with the
*temporary* password which was mailed to the new "dirty" email address in order
to get it authenticated.

If the user logs in with the old password - which is still valid - the "dirty"
email address will not be flagged as authenticated and stay "dirty". 

The existing "I forgot my password" mailer sends even to "dirty" addresses (this
seems to be reasonable), whereas the other higher level mail routines such as
EmailUser and Enotif (Email Notification when a page or user-talk page changes,
see http://bugzilla.wikipedia.org/show_bug.cgi?id=454 ) only sends to an
address, which is flagged as "authenticated" (= clean).

Vote for this, if you like it.
Can be later combined with LDAP or similar authentication systems, but works
independently as proposed herein.

Dear all,

JeLuf has asked me yesterday about the mechanism to re-login, which should be as
userfriendly as possible
Well, I mail this slightly modified mail for:

1) I forgot my password or 
2) email authentication

Mail (example):

   Someone (probably you, from IP address 192.168.1.20)
   requested that we send you a new Testwiki temporary login password.
   This message is also be sent to authenticate your email address.
   The password for user "Test User" is now "eWD1bAZ".
   You should log in with this temporary password and change it immediately.
  
http://myserver/phase3/index.php?title=Special:Userlogin&wpName=Test+User&wpPassword=eWD1bAZ&returnto=Special:Preferences

The URL is ready to click, as you will see, and fills in the required fields.
The user only has to click onto "Log in" button.
The code is ready for REL1_4 (but not in the CVS). You can check the working of
that URL with your wiki just right now, as the variables wpName and wpPassword
are used in the already existing version.

I modified SpecialUserlogin.php to have a fourth parameter $4 delivered -  which
is the urlencode($u->getName()) . In the above example, it supplies the value
"Test+User" in the link.

Remark / compatibility issues:
==============================
Having in DefaultSettings.php: $wgEmailAuthentication = false then:
==> Compatibility: fully compatible with older versions
==> User Interface: unchanged (except, that a mailaddress can already/also be
entered on the login form, if the user wishes so)

The code fully depends on a new Sysop variable $wgEmailAuthentication , with
which all dependent strings, messages and actions for Email authentication can
be enabled or disabled by Sysop (on-the fly). With "on-the fly" I mean, that
already authenticated email-addresses stay authenticated (A column
EmailAuthenticationtimestamp for this purpose is added to table user) in the
table user.

With other words: when a Sysop has run a wiki with Eauthent "on" and all or some
users have authenticated their mail addresses, these addresses will keep the
property "authenticated" as long as the addresses are not changed. However, on a
wiki with Eauthen "off", all mailing actions are performed regardless of the
authent status. (I hope, you understand: it simply works as you would expect).
Tom

I think, for security reasons, it is much better to allow the temporary password to be used for exactly one(1) log-in. One 
successful login with the temporary password clears this. 
 
The following code is used in Enotif+Eauthent 2.00: 
 
user.php 
checkpassword(): 
... 
		} elseif ( ($this->mNewpassword != '') && (0 == strcmp( $ep, $this->mNewpassword )) ) { 
			$this->mEmailAuthenticationtimestamp = wfTimestampNow(); 
			$this->mNewpassword = ''; # use this temporary password only once 
			$this->saveSettings(); 
			return true; 
... 
 

I almost (but not fully) finished my work on that.

See a preview screenshot on
http://meta.wikimedia.org/wiki/Image:En-ea_installation_form.png and enjoy
(meaning: look forward; please do not invest any time in another method at the
moment, as my method works fine. Later, we can change the behaviour together.)

Tom

EA = Email Authentication
EN = Email Notification (Enotif)
ENEA = EN+EA

-- solved a proposed with a temporary one-time password. Could be later extended
to the token method.

Changed the URL to reflect latest changes on the metawiki documentation pages
for this enhancement.

Remember to visit http://bugzilla.wikipedia.org/show_bug.cgi?id=454 with the
latest news, e-mail notification for changed user, user_talk, watched pages and,
new, for new pages and address authentication. 

E-mail address authentication solves also the old problem, that it was not
possible to add the e-mail address already in the account creation form. I also
changed the in my view potentially dangerous behaviour, that the temporary
password could be used unlimited in time in parallel to the regular account
password. With the patch, the temporary passsword is a one-time password which
allows for exactly on _one_ log-in, which authenticates the e-mail address in
the database to which it was sent as you re-login.

* The regular (existing) account password is not touched by this mechanism and
remains valid for user logins, until the user decided to change it.
* Superusers (bureaucrats, developers and sysops) do not have to authenticate
their e-mail addresses: the address for such users is immediately marked as
authenticated as it is entered on the user preference form. I programmed this
for superusers' convenience.
* The status (unauthenticated or date/time of authentication) is always shown
beneath the address on the user preferences page
* E-mail addresses are roughly checked against RFC-822 before going to be
pre-accepted for authentication cycle. This is bugzilla 959 issue.
* If a user changes her regular password to another, non-empty password, the
wiki automatically mails an temporary one-time password. 
* The user can relogin always using the regular password; this simply means,
that the new address remains unauthenticated until she decides to use once the
temporary password.

No patches are published here, because all code comes within my MediaWiki plus
ENoitf/Eauthent, even, when both "programs" can be used independently. 

Now published for MediaWiki REL1_4 (1.4.1 and pre-1.4.2).
Download URL see http://bugzilla.wikipedia.org/show_bug.cgi?id=454 

Please add you address to the CC of this bugzilla 454 [sic] , when you want
always be informed on my latest versions.
documentation http://meta.wikipedia.org/wiki/Enotif 

redesign of EAuthent as discussed with Tim on 25.04.2005

* e-mail address authentication becomes renamed to 
  e-mail address confirmation
* introducing a new column user_econfirmtoken in table user
  which is storage for the wiki-generated "econfirmtoken"
  we do not use this word in user messages, only the word '''''link'''''
* new form and new module SpecialEmailcheck.php (not going via the login screen)
* confirmation page to tell the user, that an email has been sent
* Language.php:
  suggested text:
  "A link has now been sent to you by mail. You can confirm your e-mail address
by clicking on it."
* Code and text messages are not using terms such as "temporary one-time
password" any longer
* new querystring parameter ec for something like "&ec=(econfirmttoken)"
  this value is submitted, when the user clicks onto the link in the e-mail
address confirmation mail
  when the user really requested a new (temporary) password, because he forgot
his regular one
  then the wiki sends the passwordrequest mail as usual, but answering
implicitly means, that the address to which it was sent is ''valid''.
  Therefore, this address is also marked as ''confirmed'', even when no explicit
address confirmation cycle was performed.

* e-mail address authentication becomes renamed to 
  e-mail address confirmation
* introducing a new column user_econfirmtoken in table user
  which is storage for the wiki-generated "econfirmtoken"
  we do not use this word in user messages, only the word '''''link'''''
* new form and new module SpecialEmailcheck.php (not going via the login screen)
* confirmation page to tell the user, that an email has been sent
* Language.php:
  suggested text:
  "A link has now been sent to you by mail. You can confirm your e-mail address
by clicking on it."
* Code and text messages are not using terms such as "temporary one-time
password" any longer
* new querystring parameter ec for something like "&ec=(econfirmttoken)"
  this value is submitted, when the user clicks onto the link in the e-mail
address confirmation mail
  when the user really requested a new (temporary) password, because he forgot
his regular one
  then the wiki sends the passwordrequest mail as usual, but answering
implicitly means, that the address to which it was sent is ''valid''.
  Therefore, this address is also marked as ''confirmed'', even when no explicit
address confirmation cycle was performed.

added:

* other issue, but related:
  current passwordrequest mail is also sent to unconfirmed addresses (for me,
this sounds reasonable).
  I will introduce a switch to disallow this; then, only users with a confirmed
address in the database can request a new password.

  With other words, only confirmation mail are sent to unconfirmed addresses.

  Should the user forget his password without having a confirmed e-mail address
in the database, he must call the sysop to tweak the database for "confirming"
the address (or even to store an address). See also
http://bugzilla.wikimedia.org/show_bug.cgi?id=1940 (SOS user forgot her
password, has no email address -- workaround for Sysops)

CVS HEAD REL1_5