Extension talk:ConfirmAccount

About this board


confirmaccount-welc: template transclusion on user account confirmation

1
91.201.234.159 (talkcontribs)

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

Reply to "confirmaccount-welc: template transclusion on user account confirmation"

Special:RequestAccount on Special:Login

1
TheAafi (DCW) (talkcontribs)

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,

Reply to "Special:RequestAccount on Special:Login"

Spam Reg requests bypassing Bio

3
165.0.131.172 (talkcontribs)

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?

Ethnopunk (talkcontribs)

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

LeyteWolfer (talkcontribs)

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?

Reply to "Spam Reg requests bypassing Bio"
Waterlooglass (talkcontribs)

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?

Desperately missing option to taylor displayed text

1
MwMajestix (talkcontribs)

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

Reply to "Desperately missing option to taylor displayed text"

Email address confirmation doesn't update 'user_email_authenticated'

4
TazzyTazzy (talkcontribs)

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

TazzyTazzy (talkcontribs)

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.

45.189.44.74 (talkcontribs)

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();

}

Lorenmaxwell (talkcontribs)

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


Hopefully it'll get wrapped into the extension itself.

Reply to "Email address confirmation doesn't update 'user_email_authenticated'"
Huwmanbeing (talkcontribs)

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!

134.174.140.162 (talkcontribs)

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

Lostraven (talkcontribs)

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.

Daniel K. Schneider (talkcontribs)

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 ;)

Lucamauri (talkcontribs)

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.

Reply to "Bulk clearing"
213.61.173.172 (talkcontribs)

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.

Reply to "504 Gateway Timeout"

Feature suggestion: RSS feed for new account requests

1
Swaare (talkcontribs)

An RSS feed link would be useful, since I find myself checking Watchlist every few hours to review incoming account requests. Thanks.

Reply to "Feature suggestion: RSS feed for new account requests"

Avoiding initial email address confirmation

5
Tansaku (talkcontribs)

I've got ConfirmAccount working on a mediawiki instance (1.28.1) and I notice that there's an email address confirmation step that takes place *before* the account is approved. I'm wondering if that can be removed?

I think the email might easily be missed by the user trying to create their account, and there is an email to the address when the admin confirms the account that seems to serve the same purpose, i.e. they are being informed of their account approval and being asked to reset their password.

As it stands users have to receive two email and click through on them both before and after being confirmed by an admin. I'm wondering if there's some way to remove the first email since the second one would seem to be a sufficient check ...

Coyote897 (talkcontribs)

I think this is a good suggestion/request.

Huwmanbeing (talkcontribs)

Agreed: the first email address confirmation seems unnecessary and premature — the request may not even be granted.

It seems best simply to have the user submit a request, then (if approved) get a single email telling them they're in and giving instructions on how to proceed.

Aaron Schulz (talkcontribs)

Having the email confirmed first discourages spam requests and makes it easier for admins to know how serious the request or whether they control an email from a certain domain (e.g. osu.edu or dmv.ca.gov).

80.154.14.50 (talkcontribs)

Having the email confirmed first results in accounts created with "stolen" emails potentially be flagged as spam by the real email owner. This is something that has happened to us to the point that gmail banned us because too many of their users reported our confirmation mails for spambot accounts as spam.

Reply to "Avoiding initial email address confirmation"