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.

I installed this on dcwwiki.org to stop direct account creations. However, since the extensions requires $wgGroupPermissions['*']['createaccount'] = false; inorder to work, it removes the Special:CreateAccount link from login page. Is there a way around to have Special:RequestAccount link included on the Login page. Best regards,

You could edit your MediaWiki:Loginprompt page, add there a link to Special:RequestAccount

Special:RequestAccount doesn't seem to exist on our website.

I like your extension, great work.

How do i customise the hints for entering data?

is there an option/way to doing this, without messing around in the extension's code. In special I'd like to extend/modify/set the text and/or caption in the input form to giving more 'understandible' explanation, what user should enter (such as: if field is optional. )

Have you checked the system messages with prefix confirmaccount (url: Special:AllMessages?prefix=confirmaccount)? You can edit these messages.

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.

In an docker environment of mediawiki 1.43 when installing the extension I get this error: /wiki/Special:RequestAccount Error: Call to undefined method MediaWiki\User\User::isBlockedFromCreateAccount()

It seems that the method has been deprecated.

It works to replace "$block = $user->isBlockedFromCreateAccount();" with "$block = MediaWikiServices::getInstance()->getBlockManager()->getCreateAccountBlock( $user, RequestContext::getMain()->getRequest(), true );" in includes/backend/ConfirmAccount.class.php line 319 (taken from https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaEvents/+/965269/2/includes/BlockMetrics/BlockMetricsHooks.php#16)

Feel free to submit that patch to Gerrit. This extension does not seem to be very actively maintained here.

Thank you for the feedback. I am not involved with gerrit so I don't know if I am willing to find out how to submit patches there just now.

Is it possible to transclude, not substitute, templates specified in the confirmaccount-welc message on confirming a user account?

I have constant stream of fake registration requests by somebody who appears to be bypassing the 50 word biography requirement. Should this not reject any request if user does not comply?

Oops, I didn't sign in when I posted.

I'm curious: I see you didn't get an answer here. Is this something that you solved yourself or did the problem user just go away?

Hi all,

I'm getting an error when using Chrome and Edge that says "xxxwiki.com didn’t send any data.

ERR_EMPTY_RESPONSE" when trying to complete the Request Account form. Has anyone seen this before?

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.

Automatically set the user's email as validated since they have to get validated through ConfirmAccount.

1. Must have "$wgGroupPermissions['*']['createaccount'] = false;" per ConfirmAccount extension.

$wgHooks['LocalUserCreated'][] = 'onLocalUserCreatedEmailAutoConfirm'; function onLocalUserCreatedEmailAutoConfirm( $user, $autocreated ) {

  $user->confirmEmail();
  $user->SaveSettings();

}

Thank you for such a simple fix -- this has been annoying me for years!

Hopefully it'll get wrapped into the extension itself.

As someone whose wiki is besieged by bogus account requests (from unique and variable emails and IPs), having an option to bulk reject all open requests would be enormously useful. Is this something that could be added?

If not, does anyone know of a manual way behind the scenes to easily clear out the queue en masse? Perhaps something like manually blanking a file, clearing a table, etc.?

Anything would help and be much appreciated. Thanks!

Agreed. This would be very useful. Or to filter the list to only those where the requester has confirmed their email address.

We'd also like a bulk management option. Envisioning a box next to all displayed requests, and by clicking the box (could have an option to select all requests being displayed) afterwards have an option to reject all as spam.

Agree that such a feature would be very helpful! We got a few hundreds over the last few days.

Or at least some instructions how to do this with an SQL request that does not break anything ;)

While a graphical interface would be easier and more secure to use, SQL is surely an option, I ended up routinely use it.The statement should look like this

UPDATE account_requests SET acr_rejected = LEFT(NOW(), 14), acr_deleted = '1', acr_user = 42 WHERE acr_rejected is NULL;

The query looks for unprocessed rows (with WHERE acr_rejected is NULL) then proceed to set them as rejected (with SET acr_deleted = '1'), by a specific user with userID "42" (you need to modify it with your own or any specific user of the wiki) with the timestamp of the moment when the query is executed.

I hope this helps.

Posting this "issue", so that others may find the solution faster than me:

Requesting an account will trigger an "504 Gateway Time-out" error.

/var/log/nginx/error.log:

[..]upstream timed out (110: Connection timed out) while reading response header from upstream, client: XXXXX, server: XXXXX, request: "POST /w/Spezial:Benutzerkonto_beantragen HTTP/2.0", upstream: "fastcgi://unix:/run/php/php8.0-fpm.sock", host: "XXXXX", referrer: "XXXXX/w/Spezial:Benutzerkonto_beantragen"[..]

Solution: $wgSMTP was not working because of mailserver changes. Fixed SMTP settings and everything was working again.