Topic on Extension talk:AccessControl

Hi, is there a way to use this extension together with "confirmaccount" extension? I have the problem that I can not access the confirmation Link. For example: myexamplewiki.de/index.php?title=Spezial:Benutzerkonto_beantragen&action=confirmemail&wpEmailToken=8f81128ed84b44d1e69caf8e65c381b1 I only get redirekted to access_denied page. The specialpage "Benutzerkonto_beantragen" is accessible for anonymous.

Thank you in advance ;-)

Yes. My wiki use Extension:ConfirmAccount and Extension:ConfirmEdit for captcha. First must be set $wgAutoConfirmAge . It's code from my LocalSettings.php file:

$wgGroupPermissions['autoconfirmed']['createpage'] = true;
$wgAutoConfirmAge = 6000;

and rights for namespaces:

$wgNamespaceProtection[NS_MAIN]      = array( 'autoconfirmed' );  //$wgNamespaceProtection[NS_MAIN_TALK] = array( 'autoconfirmed' $wgNamespaceProtection[NS_USER]      = array( 'autoconfirmed' ); $wgNamespaceProtection[NS_SPECIAL]   = array( 'autoconfirmed' ); $wgNamespaceProtection[NS_FILE]      = array( 'autoconfirmed' ); $wgNamespaceProtection[NS_MEDIAWIKI] = array( 'autoconfirmed' ); $wgNamespaceProtection[NS_TEMPLATE]  = array( 'autoconfirmed' ); $wgNamespaceProtection[NS_HELP]      = array( 'autoconfirmed' ); $wgNamespaceProtection[NS_CATEGORY]  = array( 'autoconfirmed' );

Bellow is registration load Extension:ConfirmAccount

wfLoadExtension( 'ConfirmAccount' );
$wgConfirmAccountContact = "admin@mywiki.domain";
$wgConfirmAccountCaptchas = true ;
$wgConfirmAccountRequestFormItems['Biography']['minWords'] = 15;

And now is part for Extension:ConfirmEdit (protection for bots)

wfLoadExtensions([ 'ConfirmEdit', 'ConfirmEdit/QuestyCaptcha' ]);
$wgCaptchaQuestions = [
// "What is the capital of Spain" => 'MADRID', // Answers are case insensitive
"What is the name of this wiki?" => $wgSitename, // You can use variables
// "How many fingers does a hand have?" => [ 5, 'five' ], // A question may have many answers
];
$wgMainCacheType    = CACHE_ANYTHING;
$wgCaptchaTriggers['edit']          = false;
$wgCaptchaTriggers['create']        = false;
$wgCaptchaTriggers['createtalk']    = false;
$wgCaptchaTriggers['addurl']        = false;
$wgCaptchaTriggers['createaccount'] = true;
$wgCaptchaTriggers['badlogin']      = false;
// This code solve confirmation e-mail address
$wgHooks['LocalUserCreated'][] = 'onLocalUserCreatedEmailAutoConfirm';
function onLocalUserCreatedEmailAutoConfirm( $user, $autocreated ) {
   $user->confirmEmail();
   $user->SaveSettings();
}

Please note that email confirmation is not needed, so it was necessary to edit the text of the message for email which is sent to account applicants.

"Please note that email confirmation is not needed" how can I disable the confirmation Email? I have set $wgEmailAuthentication = false; but still the mail is send and I can not use the confirmation Link.

OK, now I understand, the email gets send but I have to change the text to something like "You have created a wiki account and will soon receive a email with logindata" I see that I have the request alrady on the specialpage to confirm the account. But I dont get an reminder Email that there is a new Account waiting. With confirm Email working, I always got an email that an account is ready to confirm.

$wgConfirmAccountContact = "myreminder@email.whatever"

Is there a way to receive a email and use your solution? Otherwise i have to remind me myself to look sometimes for new accounts.

The Extension:ConfirmAccount has its problems. For example unsupport of the multilanguage wiki. I solve it by own system messages, which has content in main languages used on my wiki (english, polish and czech). Go to Special:AllMessages, in your wiki and find messages 'emailuserfooter', 'confirmaccount-email-body5', 'confirmaccount-email-body3', 'requestaccount-email-body'

I understand that it is annoying for you not to receive emails notifying you that an account is pending approval. But on the other hand, remember that this application is being frequently filled out by bots. If sending those alert emails were allowed, it would mean they would be spamming your bureaucrats' accounts.

At least this way the bureaucrats have a reason to check the status of the queue of pending applications from time to time. From my point of view, the extension Extension:ConfirmAccount should be rework by maintainer. To show bureaucrats notifications instead of sending emails.

If you want this functionality, enter it as a task in Phabricator, and I'll support your task. Currently I already maintain two extensions that I am working on intensively, although it is not my job. So don't get mad, but someone else has to program this functionality into the ConfirmAccount extension. Sorry.

First, I want to thank you and all the other contributors to extensions and mediawiki. I will use your solution provided bevor. I can understand your way of thinking to have all massages inside of mediawiki. In our environment we have a lot of systems and we decided to have all Information and critical massages in MS Teams so we grab the emails from AccountConfimation and other Systems and reroute them with MS PowerAutomate to special MS Teams channels. With this solution we have all relevant Data at one place for the whole Team. But it is ok to check once a week inside of Mediawiki for new Accounts so keep up the good work and thanks again for your help.

Thank you for your feedback. Unfortunately, this is a functionality that is difficult to test. And as I wrote. The correct solution is notifications, because then it's up to the user if they want to get the message by email as well. Technically, it shouldn't be a problem. See Notifications/Developer_guide . However, my experience with notifications is not yet enough to make a patch for the Extension:ConfirmAccount that would do this. The current solution is simple because it doesn't add a dependency on the Echo extension, but as I've written before, it can be a source of spam.

But it's a good reminder and I'd be very happy to hear about your experience. I don't know if you have read the original manual in English. You should definitely do so, as it also describes possible risks and solutions to specific situations. The Extension:AccessControl is based on the fact that wiki content is created by responsible users who have no interest in doing harm.