Extension talk:ConfirmAccount/archive 4

• 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.

Is it possible to customize the text provided in each section of the form provided by this extension? Or at least set some text before the extension provides the form? This will allow me to describe why this extension is necessary in my wiki.

I have found a small improvement for the extension documentation. Currently it contains "Add the following to LocalSettings.php after the line require_once "$IP/extensions/ConfirmAccount/ConfirmAccount.php";." This is outdated and does not fit to "wfLoadExtension( 'ConfirmAccount' );" in the documentation before this.

I checked Special:AllMessages for prefix=confirmaccount and found some dozens of system messages. But I did not found any of the texts provided by extension ConfirmAccount. Here is an example. My wiki is in German language. Spezial:Benutzerkonto_beantragen provides text "Die folgenden Informationen werden vertraulich behandelt..." but I cannot found this text in Special:AllMessages

The feature is provided by Extension:ConfirmAccount.

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.

Special:RequestAccount is provided by Extension:ConfirmAccount.

Awesome. I have added the Extension and this seems to help.

Today I installed this extension in my wiki. Thank you very much for this helpful extension. I recognized that this extension can be circumvent by opening Special:CreateAccount, which is directly available as a button when clicking Special:UserLogin first on the top right in MediaWiki.

Is there a way to fix this? E.g. by customizing Special:CreateAccount as a workaround?

Regards

Sorry, my fault

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

was commented out.

Regards

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.