Extension talk:ConfirmAccount

• Archive 1
• Archive 2
• Archive 3

Previous page history was archived for backup purposes at Extension talk:ConfirmAccount/LQT Archive 1 on 2015-07-10.

On upgrading from 1.31 to 1.35 I have the problem, that the link to the ConfirmLogin special page (requestaccount-loginnotice) is missing on the login special page.

I tracked this down to includes/frontend/ConfirmAccountUI.hooks.php where addRequestLoginText() should add this information to the hook. But addRequestLoginText() is never called in 1.35 (tried it out by adding a division by zero error at the top of addRequestLoginText() in both 1.31 and 1.35. Any idea, what I'm doing wrong? Anything that I have to do to enforce using the hooks?

For testing reasons I tried with a freshly created LocalSettings.php with only ConfirmLogin extension enabled but with the same result: No link to Special:RequestAccount in the login form, so this should hurt every user here...

Is you wiki private?

Then compare the workaround as in https://www.mediawiki.org/w/index.php?title=Topic:Voy0tmnffcrokxf2&topic_showPostId=vp08ljyllv3j6g6j#flow-post-vp08ljyllv3j6g6j

I'm using ConfirmAccount and ConfirmEdit extensions. Right now, when a user requests an account, they get an email asking them to confirm their email address. After clicking it on, the admin will get a notification of a new account request. After admin creates thew new account, the password is sent to the user. However, there account is still marked as not having email confirmed. In the database, the user entry for that user in the user table shows the field 'user_email_authenticated' as null while this should have a timestamp.

If the user goes through their preferences, it still says "Your email address is not yet confirmed. No email will be sent for any of the following features." If they click on that, they get yet another email asking them to confirm their email address. Eventually, this then confirms their email address and updates the database.

Why is there a need for double email confirmation? Versions: MediaWiki: 1.36.2 Confirm User Accounts: – (3195e5a) 11:46, October 7, 2021 Confirm Edit: 1.6.0

I've implemented this quick fix in my localsettings.php.

# Automatically set the user's email as validated since they have to get validated through ConfirmAccount.
# Must have "$wgGroupPermissions['*']['createaccount'] = false;" per ConfirmAccount extension.
$wgHooks['LocalUserCreated'][] = 'onLocalUserCreatedEmailAutoConfirm';
function onLocalUserCreatedEmailAutoConfirm( $user, $autocreated ) {
   $user->confirmEmail();
   $user->SaveSettings();
}

This should work since anon users can't create accounts, only admins. This also fixed the issue of the user being redirected to create an account after changing their temporary password.

I must have done something idiotic but somehow I can't make the "request account" to appear for potential new users. The mediawiki (1.34) setup is private. The extension is also 1.34 compatible. Permissions are set up as:

$wgGroupPermissions['*']['read'] = false;

with

$wgWhitelistRead = array(

  "Special:Request account",

  "Spécial:Demander un compte"

);

What is missing ?

Many thanks.

Hello, please read this post of mine. I think it could help.

Ok thanks, I've seen it, and I don't have errors (when for example using mediawiki:loginprompt to make the request account page appear).

Nevertheless, I'll have a go at what you suggest, and report here.

Hello, I did do as you suggested by adding/rewriting the hook to display the RequestAccount button. I did not touch at the ConfirmEdit bit: there are no errors showing up in the logs.

But the whole lot didn't work.

However: this feature worked with the MW version 1.33. I did not check when upgrading to 1.34 if the the feature was still alive. So, to make sure, I replaced the ConfirmAccount directory from 1.34 by the one from 1.33. And .... it did work. So I don't really know what's happening here: a quick diff on both directories didn't enlightnen me.

Conclusion: I stay with ConfirmAccount 1.33 until I have better ideas...

Here we go, I found my answer (got it of course from comparing 1.34 with 1.33):

in frontend/ConfirmAccountUI.hooks.php, line 32:

replace

if ( isset( $personal_urls['login'] ) ) {

with

if ( isset( $personal_urls['login'] )

        || isset( $personal_urls['login-private'] ) ) {

... which shows that the problem originated from my wiki being private!

Strange how this bug has yet to be fixed in REL1_35. This makes ConfirmAccount essentially useless for private wikis. Being private doesn't mean the button shouldn't appear.

The above patch solved the issue for me too, but I had to learn first, that the "Request Account" button has moved from above the login form (where it was in 1.31) to the upper right corner of the screen (where I didn't expect it after using 1.31)...

Thank you—this was a lifesaver! This was still a problem for me in version 1.36

The "Interaction diagram of a successful account creation process." illustration in Extension:ConfirmAccount#Usage does not include any New User "talk page" creation. It is the most persistent place to that the Admin/bureaucrat has to give newbie instruction to the new account holder about how to begin editing.

Our site's welcome message is a "Welcome to Gramps! We hope you will contribute much and well. You will probably want to read the help pages. Again, welcome and have fun! <approving admin name> (talk) <datestamp>"

Pretty useless. We've created a "Welcome survey" transclusion template but have to manually add it after each new user creation. (See https://www.gramps-project.org/wiki/index.php/User_talk:JohnRSibert)

But it has been SO long since the site was set up that we cannot find where to customize this message. The Manual:User creation page does not any obvious place detailing the New Account creation process... it says what triggers the User creation but does not have a flowchart of the overt steps performed by the wiki nor how to find documentation on controlling those steps.

I'd really appreciate a section on this Extension:ConfirmAccount page that lists the template pages (or documentation pages) used to generate content communicating with a new account applicant.

It should be easier to find all the interaction generators/templates if admins/bureaucrats want to customize the verbiage on:

• the new account web request form
• the eMail sent to the admin (so they can add links to New User Approval policy or blacklisted user lists)
• the confirmation eMail sent to a New User
• the Welcome message created on the New User's Talk page
• the temporary password eMail
• the log-on and change password page

I also do not know if these are the same communications that the user normally sees from the MediaWiki during "direct account creation". Googling for that "direct account creation" term only finds the ConfirmAccount extension documentation. Is there a searchable term for this process?

Thanks,

Brian

Hello, I'm getting the following when using the plugin. Any suggestions for addressing it would be appreciated.

---

[bddb5397a66d499e1af05db6] /wiki/Special:RequestAccount Error: Call to a member function timeanddate() on null

Backtrace:

from /home/litwnaqg/public_html/extensions/ConfirmAccount/includes/backend/ConfirmAccount.class.php(121)

#0 /home/litwnaqg/public_html/extensions/ConfirmAccount/includes/business/AccountRequestSubmission.php(256): ConfirmAccount::sendConfirmationMail(User, string, string, string)

#1 /home/litwnaqg/public_html/extensions/ConfirmAccount/includes/frontend/specialpages/actions/RequestAccount_body.php(343): AccountRequestSubmission->submit(RequestContext)

#2 /home/litwnaqg/public_html/extensions/ConfirmAccount/includes/frontend/specialpages/actions/RequestAccount_body.php(83): RequestAccountPage->doSubmit()

#3 /home/litwnaqg/public_html/includes/specialpage/SpecialPage.php(646): RequestAccountPage->execute(NULL)

#4 /home/litwnaqg/public_html/includes/specialpage/SpecialPageFactory.php(1386): SpecialPage->run(NULL)

#5 /home/litwnaqg/public_html/includes/MediaWiki.php(309): MediaWiki\SpecialPage\SpecialPageFactory->executePath(Title, RequestContext)

#6 /home/litwnaqg/public_html/includes/MediaWiki.php(913): MediaWiki->performRequest()

#7 /home/litwnaqg/public_html/includes/MediaWiki.php(546): MediaWiki->main()

#8 /home/litwnaqg/public_html/index.php(53): MediaWiki->run()

#9 /home/litwnaqg/public_html/index.php(46): wfIndexMain()

#10 {main}

Apparently, you are missing a line of text from the error log. Maybe you're missing a dependency?

If you could, it would be interesting if you would give out more information since I am wondering whether you installed the extension fresh out of the box or it suddenly stopped working after you updated MediaWiki.

@MarioSuperstar77 I installed a fresh version on an upgraded wiki. I installed per the instructions and all goes well until I actually try to use it, producing the backtrace above. I just rechecked.

Hello, I am getting the same errors and new users cannot request accounts. I do not have ConfirmEdit running yet. I have tried the work arounds on the extension page (actually completely broke my page). I then removed the extension and reinstalled with the latest version of the extension and still have the same issue.

Did something break with the update to Mediawiki 1.36.1?

@Scottsmithnorwich Sorry for your trouble, but glad to see I'm not the only one.

Anyone have any idea about this?

It seems like there's some issues with ConfirmAccount working with ConfirmEdit. Namely, the captcha value doesn't need to be valid in order to be submitted! Topic:Vky60p231ng9i1i4 seems to report the same issue. I can confirm this is not only affecting QuestyCaptcha but also other types such as hCaptcha, and affects versions between MediaWiki 1.31 and 1.35.

Apparently this has been an issue for nearly 4 years. https://phabricator.wikimedia.org/T168783

Borrowing Kghbln's terminology in another thread, an immediate but not final solution is offered here for hCaptcha only. (It is not very pretty and needs a lot of revising to commit to the codebase, but it works as a patch.) Make patches to the following files by replacing their contents with the contents in the link:

MediaWiki 1.35+:

• includes/frontend/specialpages/actions/RequestAccount_body.php: https://github.com/mywikis/ConfirmAccount/blob/2f4eca54480992f78a5883d3be9dc04deba6d047/includes/frontend/specialpages/actions/RequestAccount_body.php
• includes/business/AccountRequestSubmission.php: https://github.com/mywikis/ConfirmAccount/blob/2f4eca54480992f78a5883d3be9dc04deba6d047/includes/business/AccountRequestSubmission.php

MediaWiki 1.31:

• frontend/specialpages/actions/RequestAccount_body.php: https://github.com/mywikis/ConfirmAccount/blob/fe985841feb6501de5dcfc2bf2dc723cd4ef5ab9/frontend/specialpages/actions/RequestAccount_body.php
• business/AccountRequestSubmission.php: https://github.com/mywikis/ConfirmAccount/blob/fe985841feb6501de5dcfc2bf2dc723cd4ef5ab9/business/AccountRequestSubmission.php

FAQs:

1. You might ask, how would I get hCaptcha working on MediaWiki 1.31 when it is only for MediaWiki 1.35+?

Simple, just make sure you change line 139 protected function addCaptchaAPI( (as seen at https://github.com/wikimedia/mediawiki-extensions-ConfirmEdit/blob/master/hCaptcha/includes/HCaptcha.php#L139) to public function addCaptchaAPI(. That's it! Follow instructions for installing hCaptcha as normal otherwise and ignore the fact that it is only made for 1.35+. Another issue might appear that will cause pages such as Special:CreateAccount to error with the call to the addCSPSources() method on line 41 of HTMLHCaptchaField.php, but it can be fixed by removing that function call, since MediaWiki 1.31 doesn't offer support for this (as seen at https://github.com/wikimedia/mediawiki-extensions-ConfirmEdit/blob/master/hCaptcha/includes/HTMLHCaptchaField.php#L41).

2. Why does this patch only work for hCaptcha?

The way that ConfirmEdit and ConfirmAccount work together currently to "handle" captchas (or more precisely, don't handle captchas) is not easily fixable. This interim solution simply enables the form to accept the necessary captcha fields and adds a cURL request to the hCaptcha endpoint and evaluates its response. This was pretty easy to implement without referring to too many ConfirmEdit configuration variables and functions. We only made this patch for hCaptcha because MyWikis has moved to using hCaptcha on all wikis instead of QuestyCaptcha or reCAPTCHA. Our reasons for this choice are listed on our blog, and in our experience, reCAPTCHA is useless and has long been cracked by spambots. If you have a compelling reason for us to develop a temporary patch for QuestyCaptcha, leave a message below.

3. Are there any known issues with this patch?

I should note there is a small bug where hCaptcha doesn't populate the token passed along in the form submission if you previously submitted the form and ConfirmAccount gave you an error. But the patch makes up for it by adding an error message that encourages the user to leave and come back to the page to try again. Plus, nobody would be submitting the page without a captcha done in the first place except by mistake.

There seems to be an issue in some environments for MW 1.35.x, probably also for other versions. Tracked with task T275522.

Turns out that the extension is not yet up for requests from users with IPv6. :|

An immediate but not final solution is offered at task T275522

How do I make the Real Name a required field in the MW 1.35 LocalSettings.php. I have the following

defined in LocalSettings.php after the extension is loaded

## option to create User: page set to true

$wgMakeUserPageFromBio = true;

## option to create User talk: page set to true

$wgAutoWelcomeNewUsers = true;

$wgConfirmAccountRequestFormItems = [
    'UserName'        => [ 'enabled' => true ],
    'RealName'        => [ 'enabled' => true ],
    'Biography'       => [ 'enabled' => true, 'minWords' => 1 ],
    'AreasOfInterest' => [ 'enabled' => false ],
    'CV'              => [ 'enabled' => false ],
    'Notes'           => [ 'enabled' => false ],
    'Links'           => [ 'enabled' => false ],
    'TermsOfService'  => [ 'enabled' => true ],
];

In testing I am able to submit a request account with an empty field for the real name, which we use in the User: profile

Extension:ConfirmAccount page indicates

The default values are in ConfirmAccount.config.php, but you should not edit that file.

but I am not able to find that file.

I posted the question on the Support Desk

Topic:W154oo8jj3wwk5go

but maybe it should be posted here

I was trying to figure out why the lang.json files are not being used to send out the approval email in the language the request was submitted in by the user when I noticed the email message was very different than the "confirmaccount-email-body": in line 82 of the wiki/extensions/ConfirmAccount/i18n/requestaccount/en.json

Looks like the account created email message is coming from the wiki/languages/i18n/en.json file

"createaccount-text": "The account you requested for this email address on MediaWiki ($4) named \"$2\", with a temporary password \"$3\" has been created.\nYou should log in and change your password now.\n\nYou may ignore this message, if this account was created in error.",

and is being issued by the wiki/includes/auth/TemporaryPasswordPrimaryAuthenticationProvider.php

in the function sendNewAccountEmail

It also appears that the following instruction

       $userLanguage = $user->getOption( 'language' );

does not get the language used by the user when Registering for a Username

Why is the ConfirmAccount not issuing the email?

I upgraded to MediaWiki 1.35.1 over the weekend and I cannot find where the Account created email is coming from.

It now starts with

Someone created an account for your email address on TNG Wiki ...

Can someone please identify where that message is within MediaWiki 1.35.1

Installed software

Product     Version

MediaWiki     1.35.1

PHP     7.4.9 (cgi-fcgi)

MySQL     5.7.31-percona-sure1-log

ICU     63.1

Lua     5.1.5

$wgDefaultSkin = "vector";

Extensions

wfLoadExtension( 'CategoryTree' );

wfLoadExtension( 'Cite' );

wfLoadExtension( 'CiteThisPage' );

wfLoadExtension( 'CodeEditor' );

wfLoadExtension( 'CollapsibleVector' );

wfLoadExtension( 'ConfirmAccount' );

wfLoadExtension( 'ConfirmEdit' );

wfLoadExtension( 'EditUser' );

wfLoadExtension( 'Gadgets' );

require_once "$IP/extensions/GoogleTranslator/GoogleTranslator.php";

wfLoadExtension( 'ImageMap' );

wfLoadExtension( 'InputBox' );

require_once "$IP/extensions/LanguageSelector/LanguageSelector.php";

wfLoadExtension( 'LocalisationUpdate' );

wfLoadExtension( 'Lockdown' );

require_once "$IP/extensions/MobileDetect/MobileDetect.php";

wfLoadExtension( 'MobileFrontend' );

wfLoadExtension( 'MyVariables' );

wfLoadExtension( 'NewUserMessage' );

wfLoadExtension( 'ParserFunctions' );

wfLoadExtension( 'Poem' );

require_once "$IP/extensions/Polyglot/Polyglot.php";

wfLoadExtension( 'Renameuser' );

wfLoadExtension( 'ReplaceText' );

wfLoadExtension( 'Scribunto' );

wfLoadExtension( 'SecureLinkFixer' );

wfLoadExtension( 'SyntaxHighlight_GeSHi' );

wfLoadExtension( 'TemplateData' );

wfLoadExtension( 'TextExtracts' );

wfLoadExtension( 'TitleKey' );

wfLoadExtension( 'UserMerge' );

wfLoadExtension( 'VisualEditor' );

wfLoadExtension( 'WikiEditor' );

working on getting the ConfirmAccount Request Account form in different languages on the same wiki using LanguageSelector. Have most of it working, but cannot find where the account created message is defined. It is not in the ConfirmAccount en.json files

Thanks in advance for any help you all can provide

Mea culpa,

It is heck getting old and upgrading MediaWiki software only every 3 years or so. I completely forgot that I had changed that message when I upgraded to MW 1.27.3

It would be nice though if the account approved email came from the ConfirmAccount extension confirmaccount-email-body message instead the generic createaccount-text in the wiki/languages/i18n json files

Sorry raising this issue

I have the same issue, and I have to change createaccount-text for the moment to work it out.

a user who has confirmed his or her e-mail for account creation has to again confirm the e-mail for mediawiki once the account was created. Requiring e-mail confirmation twice is really bad.