This is *not* a blocker for wikis with OpenID as long as the standard password-login is not disabled ( $wgOpenIDOnly == false ).

No changes / updates for five weeks here - is this really highest priority (which implies some urgency)?

this is a * yes- keep alive ping - busy with even more important thing - this is not cookie licking *

Downgraded to normal. No user has complained so far.

"high" is more appropriate.

In short, this is the

"I-cannot-set-up-my-e-mail-address-because-I-do-not-know-my-password" problem.

It came up when MediaWiki core changed and required the account password, when users want to set-up or change their e-mail address (which makes definitely sense for security reasons).

If someone can help to find a solution, pls. let me know a.s.a.p.

We may want to allow a hook to update that part of the interface, so we could have OpenID (or similar extensions) remove it, whereas other extensions might want to do a 2nd factor check there.

Aaron might have another idea, since he implemented the check (iirc).

(In reply to comment #7)

We may want to allow a hook to update that part of the interface, so we could
have OpenID (or similar extensions) remove it, whereas other extensions might
want to do a 2nd factor check there.

Aaron might have another idea, since he implemented the check (iirc).

ok.

Please be reminded, that I already introduced a special way for the special case of $wgOpenIDOnly==true

This was fixed in 2011 in https://bugzilla.wikimedia.org/show_bug.cgi?id=29027 . See https://bugzilla.wikimedia.org/show_bug.cgi?id=29027#c1 for a detailed description (copied to here for convenience):

"fixed in r88848 .

When having the OpenID extension, the preference window basic information is
changed. The section "Password" shows now links to

case i) Change Password and Reset Password:

if a password already exists

case ii) Reset Password only:

if no password has been set for this account yet, because the user opened their
account by OpenID - which setPassword( null )

This is at least one possible way and avoids modification of
Special:PasswordReset (there is no login page when only OpenID logins and
account creations are possible ($wgOpenIDOnly==true) or Special:ChangePassword
pages."

I will add this hardening ad-hoc fix to prevent problems in the future:

*Disallow* wiki account creation in the case

• new user wants to create an account (with their OpenID) and
• $wgOpenIDOnly=true (i.e. logins and account creations are only allowed via OpenID) and
• no e-mail address present, or e-mail address fails the Sanitizer:validEmail() test.

This avoids any account creation without e-mail address, which makes sense because the user could not change ro setup their password without having a (confirmed) e-mail address in their wiki account.

(In reply to T. Gries from comment #6)

In short, this is the

"I-cannot-set-up-my-e-mail-address-because-I-do-not-know-my-password"
problem.

It came up when MediaWiki core changed and required the account password,
when users want to set-up or change their e-mail address (which makes
definitely sense for security reasons).

If someone can help to find a solution, pls. let me know a.s.a.p.

Since MW 1.20.0 there is the $wgRequirePasswordforEmailChange parameter. Shouldn't this solve the issue. However, when talking about MW 1.19 we are still out of luck. However there are only 11 months of support left with the succeeding LTS already released.

[1] https://www.mediawiki.org/wiki/Manual:$wgRequirePasswordforEmailChange

@kgh thx for pointing me to this

You are welcome. I wish I had seen this bug before. However the big Kudos go to Reedy who made this parameter reality. This one was a life-saver on several of my wikis.