Probably ArticleCreationWorkflow?

In T204016#4573022, @revi wrote:

Probably ArticleCreationWorkflow?

Thanks. That brings us to:

'wmgUseArticleCreationWorkflow' => [
	// ..
	'enwiki' => true, // T192455
],

'wgArticleCreationWorkflows' => [
	// ..
	'enwiki' => [
		[
			'namespaces' => [ 0 ],
			'excludeRight' => 'autoconfirmed'
		],
	],
],

I suppose, of course, that the interception performed by that extension is bypassed if someone uses the API.

I'd think the fix for this would be to make article-namespace creation its own right, given only to autoconfirmed & confirmed users, but there're probably other ways to do this.

In T204016#4573024, @APerson wrote:

I'd think the fix for this would be to make article-namespace creation its own right, given only to autoconfirmed & confirmed users, but there're probably other ways to do this.

Or make ArticleCreationWorkflow stop API requests when submitted by nonconfirmed?

In T204016#4573024, @APerson wrote:

I'd think the fix for this would be to make article-namespace creation its own right, [..], but there're probably other ways to do this.

Yeah, for example, we have the below code used for editing of the Draft-namespace, which uses a hook that I believe is generic enough to also apply to the API.

{
	// If it's an anonymous user creating a page in the English and Persian Wikipedia
	// Draft namespace, tell TitleQuickPermissions to abort the normal
	// checkQuickPermissions checks.  This lets anonymous users create a page in this
	// namespace, even though they don't have the general 'createpage' right.
	//
	// It does not affect other checks from getUserPermissionsErrorsInternal
	// (e.g. protection and blocking).
	//
	// Returning true tells it to proceed as normal in other cases.
	$wgHooks['TitleQuickPermissions'][] = function ( Title $title, User $user, $action, &$errors, $doExpensiveQueries, $short ) {
		return ( $action !== 'create' || $title->getNamespace() !== 118 || !$user->isAnon() );
	};
}

The extension isnt documented as restricting anything and doesnt hook into the mediawiki permission system...so that seems to be working as intended? (It does have code to not give the redirect to some people but thats not really documented as a security measure)

I feel this is less a security bug and more a request for config change.

edit: https://en.wikipedia.org/wiki/Wikipedia:Autoconfirmed_article_creation_trial/Request_for_comment_on_permanent_implementation i guess makes it pretty clear that the community intention is for this to be restricted. The ArticleCreationWorkflow extension would need to use different hooks if it intends to enforce that.

Anyway, personally I think the various user rights exceptions with hooks are really confusing and getting out of hand. I think we should do things around "rights" and assign things to groups, for clarity's sake. So something (based on the viewdeletedfile right) along the lines of:

From 4b7092d081285ba64126998d9becbf34a216c4fd Mon Sep 17 00:00:00 2001
From: Brian Wolff <bawolff+wn@gmail.com>
Date: Tue, 11 Sep 2018 05:06:12 +0000
Subject: [PATCH] Adjust user rights to require autoconfirm to create main NS
 pages on enwiki

Bug: T204016
---
 wmf-config/CommonSettings.php     | 21 +++++++++++++++++++++
 wmf-config/InitialiseSettings.php |  5 +++++
 2 files changed, 26 insertions(+)

diff --git a/wmf-config/CommonSettings.php b/wmf-config/CommonSettings.php
index ac8b55f..161355c 100644
--- a/wmf-config/CommonSettings.php
+++ b/wmf-config/CommonSettings.php
@@ -763,6 +763,27 @@ $wgHooks['TitleQuickPermissions'][] = function ( Title $title, User $user, $acti
 	return ( !in_array( $action, [ 'deletedhistory', 'deletedtext' ] ) || !$title->inNamespaces( NS_FILE, NS_FILE_TALK ) || !$user->isAllowed( 'viewdeletedfile' ) );
 };
 
+// T204016
+$wgAvailableRights[] = 'createpagenonmainns';
+$wgHooks['TitleQuickPermissions'][] = function ( Title $title, User $user, $action, &$errors, $doExpensiveQueries, $short ) {
+	$ns = $title->getNamespace();
+	return !(
+		$action === 'create' &&
+		!$this->isTalkPage() &&
+		!$title->inNamespace( NS_MAIN ) &&
+		$user->isAllowed( 'createpagenonmainns' )
+	);
+};
+$wgAvailableRights[] = 'createpagemainns';
+$wgHooks['TitleQuickPermissions'][] = function ( Title $title, User $user, $action, &$errors, $doExpensiveQueries, $short ) {
+	$ns = $title->getNamespace();
+	return !(
+		$action === 'create'
+		$title->inNamespace( NS_MAIN ) &&
+		$user->isAllowed( 'createpagemainns' )
+	);
+};
+
 if ( $wmgUseTimeline ) {
 	include "$wmfConfigDir/timeline.php";
 }
diff --git a/wmf-config/InitialiseSettings.php b/wmf-config/InitialiseSettings.php
index c888299..875c247 100644
--- a/wmf-config/InitialiseSettings.php
+++ b/wmf-config/InitialiseSettings.php
@@ -8699,6 +8699,11 @@ $wgConf->settings = [
 			'move' => false, // autoconfirmed only
 			'collectionsaveasuserpage' => true, // T48944
 			'changetags' => false, // T97013
+			'createpage' => false,
+			'createpagenonmainns' => true
+		],
+		'autoconfirmed' => [
+			'createpagemainns' => true
 		],
 		'founder' => [ 'userrights' => true ],
 		'rollbacker' => [ 'rollback' => true ],
-- 
2.8.1

In T204016#4573077, @Bawolff wrote:

Anyway, personally I think the various user rights exceptions with hooks are really confusing and getting out of hand. I think we should do things around "rights" and assign things to groups, for clarity's sake.

+1 to that, although adding new rights controlling existing actions can be kind of weird either way.

So something (based on the viewdeletedfile right) along the lines of:

It depends on the model we want the right to follow.

'viewdeletedfile' is giving the user a permission they don't already have, so it needs to bypass the normal checks in Title::checkQuickPermissions() that would prevent the action.

If we want 'createpagenonmainns' and 'createpagemainns' to work the same, overriding the lack of 'createtalk'/'createpage', then the patch you supplied is more or less correct. Except you're removing 'createpage' from everyone in favor of assigning both 'createpagenonmainns' and 'createpagemainns' to autoconfirmed, which might confuse other code that checks for 'createpage' (e.g. the PermissionsError exceptions thrown by EditPage, or Special:NewPages).

We could instead make it so you need both 'createpage' and 'createpagemainns' to create a page in the main namespace, like how you need both 'editinterface' and 'editsitejs' to edit MediaWiki:Common.js. In that case,

// T204016
$wgAvailableRights[] = 'createpagemainns';
$wgHooks['TitleQuickPermissions'][] = function ( Title $title, User $user, $action, &$errors, $doExpensiveQueries, $short ) {
	if (
		$action === 'create'
		$title->inNamespace( NS_MAIN ) &&
		!$user->isAllowed( 'createpagemainns' )
	) {
		$errors[] = $user->isAnon() ? [ 'nocreatetext' ] : [ 'nocreate-loggedin' ];
		return false;
	}
	return true;
}

This way gives the opportunity to use WikimediaMessages to add custom messages for this situation, too.

Would Community-Tech be able to work on remediating this issue, as the team that worked on this feature initially?

@Bawolff I will raise this in our team meeting to get the team's thoughts on this.
CC @kaldari - your input would be helpful.

@Niharika - Clearly, MediaWiki needs a new user right to properly support English Wikipedia's article creation restrictions. Since CommTech built ArticleCreationWorkflow it seems logical for them to work on it. I don't think it would take a huge amount of work, but it would require some careful changes in core.

The ArticleCreationWorkflow solution is hacky, but it was basically an emergency solution to prevent the English Wikipedia from implementing a much worse solution on their own (restricting article creation via AbuseFilters). If the team feels they don't have bandwidth to implement the new user right, the existing hack (which just uses some hooks and config values) could be extended to the API. I know CommTech has a lot on their plate right now, and they shouldn't be punished for voluntarily taking on the ACTRIAL work. At the same time, I imagine they would feel some satisfaction at being able to come back to this problem and fix it the "right way", so I would love to see CommTech take it on if they're willing to.

As a temporary measure I created https://en.wikipedia.org/wiki/Special:AbuseFilter/934 which disallows page creations by unconfirmed users, which should apply to API edits. Is the loophole of being able to use the API the only concern?

Also, doesn't the mobile app use the API? If so the filter obviously is not so great, because good-faith users could author an entire article only to find they can't save it, as opposed to being redirected to https://en.wikipedia.org/wiki/Wikipedia:New_user_landing_page before they write anything.

@Bawolff A concern was raised in the team that this is potentially quite heavier than a relatively quick security fix; it involves some potential back-and-forth on how to handle the behavior.

Now that we have the abuse filter that @MusikAnimal created, which seems to block the loophole itself on English Wiki, and considering that this only is enabled on English WIki at all, can we work on a followup fix as non-security? As in, can we have it on gerrit, going formal review?

In T204016#4598875, @Mooeypoo wrote:

@Bawolff A concern was raised in the team that this is potentially quite heavier than a relatively quick security fix; it involves some potential back-and-forth on how to handle the behavior.

Now that we have the abuse filter that @MusikAnimal created, which seems to block the loophole itself on English Wiki, and considering that this only is enabled on English WIki at all, can we work on a followup fix as non-security? As in, can we have it on gerrit, going formal review?

Yep, that sounds fine. Would you like me to make this ticket public as well?

In T204016#4600034, @Bawolff wrote:

Yep, that sounds fine. Would you like me to make this ticket public as well?

That would be awesome, if that works. We can then make this part of our usual dev/review/QA process.

Thanks!

Question: should this return a custom error instead of generic 'nocreatetext'/'nocreate-loggedin'? It will only be visible to the API so the question here is whether a more clear error message is better than an error code suddenly appearing that clients aren't aware of.

Change 462037 had a related patch set uploaded (by MaxSem; owner: MaxSem):
[mediawiki/extensions/ArticleCreationWorkflow@master] Truly prevent page creation, add a permission

https://gerrit.wikimedia.org/r/462037

Change 462040 had a related patch set uploaded (by MaxSem; owner: MaxSem):
[operations/mediawiki-config@master] Introduce new ArticleCreationWrokflow permissions

https://gerrit.wikimedia.org/r/462040

Change 462041 had a related patch set uploaded (by MaxSem; owner: MaxSem):
[operations/mediawiki-config@master] Remove old ArticleCreationWorkflows config

https://gerrit.wikimedia.org/r/462041

Change 462037 merged by jenkins-bot:
[mediawiki/extensions/ArticleCreationWorkflow@master] Truly prevent page creation, add a permission

https://gerrit.wikimedia.org/r/462037

Change 462040 merged by jenkins-bot:
[operations/mediawiki-config@master] Introduce new ArticleCreationWrokflow permissions

https://gerrit.wikimedia.org/r/462040

@MaxSem - Now that this has been merged, please add documentation at https://www.mediawiki.org/wiki/Manual:User_rights#List_of_permissions (and anywhere else it is needed). Seems like this probably also warrants a mention in the ReleaseNotes if that hasn't been done already. Thanks.

It's not a core right so it doesn't belong in core documentation.

Got it. In that case, please document at https://www.mediawiki.org/wiki/Extension:ArticleCreationWorkflow, or wherever is appropriate.

I've attempted some documentation update at https://www.mediawiki.org/wiki/Extension:ArticleCreationWorkflow

Thanks @Samwilson. Nice work on this @MaxSem.

@chasemp, please either close this or unassign me from it since I can't even do this myself anymore.

@MaxSem would you mind trying to resolve this now?

We should switch the AbuseFilter to be tag-only and make sure the new patch is working correctly. I tried to create a new tag for it, disallowed page creation, but for some reason it won't let me add it. Maybe @MusikAnimal could help.

I tried disabling the filter for a moment, attempt to create a page via the API produced this, as expected:

{
    "error": {
        "code": "cantcreate",
        "info": "You do not have permission to create new pages.",
        "*": "See https://en.wikipedia.org/w/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes."
    },
    "servedby": "mw1229"
}

@chasemp, I still can't close it.

@chasemp, I still can't close it.

@MaxSem ..last ask I promise, could you try to resolve this? We worked on our perms issue for other similar tasks and I think it's in a known state now.

Change 462041 merged by jenkins-bot:
[operations/mediawiki-config@master] Remove old ArticleCreationWorkflows config

https://gerrit.wikimedia.org/r/462041