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?
Extension talk:ConfirmAccount
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.
An RSS feed link would be useful, since I find myself checking Watchlist every few hours to review incoming account requests. Thanks.
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 ...
I think this is a good suggestion/request.
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.
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).
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.
| Product | Version |
|---|---|
| MediaWiki | 1.39.3 |
| PHP | 8.1.18 (apache2handler) |
| MySQL | 5.7.41 |
| ICU | 67.1 |
Suddently the following error start to occur when attempt to create a new account:
[DBQuery] LCStoreDB::get [0s] mysql: SELECT lc_value FROM `l10n_cache` WHERE lc_lang = 'en' AND lc_key = 'messages:confirmaccount-autorej' LIMIT 1
[DBQuery] ConfirmAccount::runAutoMaintenance [0s] mysql: UPDATE `account_requests` SET acr_rejected = '20230424145435',acr_user = 0,acr_comment = '(this request has automatically been discarded due to inactivity)',acr_deleted = 1 WHERE (acr_rejected IS NULL) AND (acr_registration < '20230325145435') AND (acr_held < '20230325145435' OR acr_held IS NULL)
[exception] [87bde0f9f7ab92e3859186bc] /xds/index.php/Special:RequestAccount PHP Fatal Error from line 49 of /var/www/html/includes/http/MWCallbackStream.php: Declaration of MWCallbackStream::write($string) must be compatible with Psr\Http\Message\StreamInterface::write(string $string): int
#0 [internal function]: MWExceptionHandler::handleFatalError()
#1 {main}
[session] Saving all sessions on shutdown
Hi S0ring
Is your above issue is resolved, Iam also facing same issue when trying to edit any page.
please let me know what changes u have done for this to resolve.?
Fatal error: Declaration of MWCallbackStream::write($string) must be compatible with Psr\Http\Message\StreamInterface::write(string $string): int in /var/www/html/includes/http/MWCallbackStream.php on line 49
If I remember correctly, the issue has been resolved updating the version of the extension.
The current version I use is:
| Confirm User Accounts | – (923b5a8) 07:14, 2. Mai 2023 |
Hi I installed Version 1.39 in Mediawiki 1.39 but wenn I try to register a new Account I get a confirmation Email with a link like this:
xttp:///index.php?title=Spezial:Benutzerkonto_beantragen&action=confirmemail&wpEmailToken=3f21aa4c891e8c3a3416feec0bdf59ab
The base URL is missing there is only three ///
Does anyone know the reason for this ??
Thanks!
I changed http to xttp to go around Filters
Hello.
I also have this issue, but I am not using the ConfirmAccount extension. Didn't manage to dig up any other mentions of this issue other than this one here. I looked around in the Mediawiki source code as well, but got stuck there eventually since I don't know enough about tokens nor PHP.
I recently updated (1.31->1.35->1.39) and switched my server to GoogleLogin in authoritative mode (usernames now have an @), so maybe it is somehow connected to that?
Hello everyone,
same situation on our server, too (1.3.9).
The main server url is missing in the confirmation email. Does one of you know this problem and has a workaround for me/us?
Thanks in advance!
Matt
MediaWiki 1.39.0
PHP 7.4.33 (cgi-fcgi)
MariaDB 10.5.19-MariaDB
Same issue here. Upgraded from 1.35 to 1.39 on Monday, and now the emails sent from this extension do not include the proper Server URL. Not only is the domain name missing, but it is using http instead of https in the message. This is making it difficult both for Beauracrats to confirm account requests, but also for requesters to confirm their email addresses when they make a request.
TL;DR: Try setting $wgCanonicalServer on LocalSettings.php.
I have an MW instance behind a reverse proxy. Proxy handles HTTPS protocol, and comunicates with MW through HTTP. My $wgServer is nicely configured and states the public DNS name with HTTPS protocol, but my ConfirmAccount confirmation mails where missing the DNS name of my site. I noted the 'http' procotocol definition on the mail body; wrong! May it relate to the origin URL on the headers stating HTTP protocol? So just tried setting the $wgCanonicalServer on LocalSettings.php and got it working at first try.
The interaction diagram shows the email sent to admins after the account request is made. But the text under "troubleshooting" explicitly notes that the email is not sent until the user has confirmed their own email. To quote "... note that a user must first confirm their email address through the link emailed to them, and then the email will be sent to the bureaucrat to confirm the account."
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.
- Must have "$wgGroupPermissions['*']['createaccount'] = false;" per ConfirmAccount extension.
$wgHooks['LocalUserCreated'][] = 'onLocalUserCreatedEmailAutoConfirm'; function onLocalUserCreatedEmailAutoConfirm( $user, $autocreated ) {
$user->confirmEmail(); $user->SaveSettings();
}
Hoping this is an easy one. Here is the backtrace. Happens when I hit the "Create Account" button.
[Yve--N0CrNL3S_ildqFUjAAAABM] /wiki/index.php?title=Special:CreateAccount&returnto=Special:ConfirmAccounts/authors Error: Call to undefined method User::setOption()
Backtrace:
from /usr/local/www/apache24/data/wiki/skins/Vector/includes/Hooks.php(220)
#0 /usr/local/www/apache24/data/wiki/includes/HookContainer/HookContainer.php(338): Vector\Hooks::onLocalUserCreated(User, boolean)
#1 /usr/local/www/apache24/data/wiki/includes/HookContainer/HookContainer.php(137): MediaWiki\HookContainer\HookContainer->callLegacyHook(string, array, array, array)
#2 /usr/local/www/apache24/data/wiki/includes/HookContainer/HookRunner.php(2370): MediaWiki\HookContainer\HookContainer->run(string, array)
#3 /usr/local/www/apache24/data/wiki/includes/auth/AuthManager.php(1503): MediaWiki\HookContainer\HookRunner->onLocalUserCreated(User, boolean)
#4 /usr/local/www/apache24/data/wiki/includes/auth/AuthManager.php(1217): MediaWiki\Auth\AuthManager->continueAccountCreation(array)
#5 /usr/local/www/apache24/data/wiki/includes/specialpage/AuthManagerSpecialPage.php(376): MediaWiki\Auth\AuthManager->beginAccountCreation(User, array, string)
#6 /usr/local/www/apache24/data/wiki/includes/specialpage/AuthManagerSpecialPage.php(502): AuthManagerSpecialPage->performAuthenticationStep(string, array)
#7 /usr/local/www/apache24/data/wiki/includes/htmlform/HTMLForm.php(726): AuthManagerSpecialPage->handleFormSubmit(array, VFormHTMLForm)
#8 /usr/local/www/apache24/data/wiki/includes/specialpage/AuthManagerSpecialPage.php(435): HTMLForm->trySubmit()
#9 /usr/local/www/apache24/data/wiki/includes/specialpage/LoginSignupSpecialPage.php(314): AuthManagerSpecialPage->trySubmit()
#10 /usr/local/www/apache24/data/wiki/includes/specialpage/SpecialPage.php(671): LoginSignupSpecialPage->execute(NULL)
#11 /usr/local/www/apache24/data/wiki/includes/specialpage/SpecialPageFactory.php(1378): SpecialPage->run(NULL)
#12 /usr/local/www/apache24/data/wiki/includes/MediaWiki.php(315): MediaWiki\SpecialPage\SpecialPageFactory->executePath(string, RequestContext)
#13 /usr/local/www/apache24/data/wiki/includes/MediaWiki.php(912): MediaWiki->performRequest()
#14 /usr/local/www/apache24/data/wiki/includes/MediaWiki.php(563): MediaWiki->main()
#15 /usr/local/www/apache24/data/wiki/index.php(53): MediaWiki->run()
#16 /usr/local/www/apache24/data/wiki/index.php(46): wfIndexMain()
#17 {main}
Nevermind, I fixed it. Skin was bad. Sorry for the noise!