Page MenuHomePhabricator

ArticleCreationWorkflow does not actually enforce enwp's autoconfirmed requirement for page creation in the permission system
Closed, ResolvedPublic8 Story PointsSecurity

Description

enterprisey wrote at #wikimedia-operations:

possible bad config change? mainspace article was just created by new user on enwp with no permissions https://en.wikipedia.org/wiki/How_can_i_create_new_article%3F%3F

User log:

  • https://en.wikipedia.org/wiki/Special:Log/Testaccount20191
  • 17:07, 10 September 2018 - User account was created
  • 18:01, 10 September 2018 Testaccount20191 created page User:Testaccount20191
  • 22:02, 10 September 2018 Testaccount20191 created page User:Testaccount20199/Test
  • 22:44, 10 September 2018 Testaccount20191 created page User:Testaccount20191/Tr
  • 01:56, 11 September 2018 Testaccount20191 created page How can i create new article??

Details

Related Gerrit Patches:
operations/mediawiki-config : masterRemove old ArticleCreationWorkflows config
operations/mediawiki-config : masterIntroduce new ArticleCreationWrokflow permissions
mediawiki/extensions/ArticleCreationWorkflow : masterTruly prevent page creation, add a permission

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

From what I can tell, there is nothing in the MediaWiki settings that would prevent registered users from creating a page. I only see such setting for anonymous users, which appears to be working as intended. Is createpage meant to restricted to autoconfirmed?

/ping @kaldari, @tstarling, P2059

A few relevant settings:

'wgAutoConfirmAge' => [
	'default' => 4 * 3600 * 24, // 4 days
  // ..
],

'wgAutoConfirmCount' => [
	'enwiki' => 10,
 // ..
],

'groupOverrides' => [
	'enwiki' => [
		'*' => [ 'createpage' => false ], // See P2059
	],
  // ..
],
Krinkle merged a task: Restricted Task.Sep 11 2018, 3:12 AM
Krinkle added subscribers: APerson, jrbs, revi.
Krinkle renamed this task from Is autoconfirm is as expected on en.wikipedia.org? to Is createpage restriction working as expected on en.wikipedia.org?.Sep 11 2018, 3:16 AM

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.

revi added a comment.Sep 11 2018, 3:20 AM

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?

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.

CommonSettings.php
{
	// 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() );
	};
}
Bawolff added a subscriber: Bawolff.EditedSep 11 2018, 4:02 AM

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.

Legoktm renamed this task from Is createpage restriction working as expected on en.wikipedia.org? to ArticleCreationWorkflow does not actually enforce enwp's autoconfirmed requirement for page creation in the permission system.Sep 11 2018, 4:24 AM
Legoktm triaged this task as High priority.
Legoktm added a subscriber: Legoktm.

T192455: Permanently implement autoconfirmed-account-requirement for new article creation on en.wiki is pretty clear that the intention was that non-autoconfirmed users shouldn't be able to create pages. I set priority to high because the status quo isn't correct, but not UBN because well, it's been an issue for this long without anyone noticing :/

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
Anomie added a subscriber: Anomie.Sep 11 2018, 12:07 PM

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.

alanajjar added a parent task: Restricted Task.Sep 11 2018, 7:05 PM

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.

Niharika set the point value for this task to 8.Sep 18 2018, 11:10 PM
MusikAnimal added a subscriber: MusikAnimal.EditedSep 19 2018, 12:27 AM

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?

@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?

Power removed a subscriber: Power.Sep 20 2018, 1:21 AM

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!

Restricted Application added a project: Security. · View Herald TranscriptSep 20 2018, 5:15 PM
kaldari changed the visibility from "Custom Policy" to "Public (No Login Required)".
MaxSem claimed this task.Sep 21 2018, 7:24 PM
MaxSem moved this task from Ready to In Development on the Community-Tech-Sprint board.

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

chasemp removed a parent task: Restricted Task.Oct 26 2018, 6:11 PM
chasemp added a project: Restricted Project.Oct 26 2018, 6:16 PM
chasemp changed the subtype of this task from "Task" to "Security Issue".Oct 26 2018, 7:13 PM
chasemp raised the priority of this task from High to Unbreak Now!.Oct 26 2018, 7:19 PM
chasemp moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.
Restricted Application added subscribers: Liuxinyu970226, TerraCodes. · View Herald TranscriptOct 26 2018, 7:19 PM

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

Thanks @Samwilson. Nice work on this @MaxSem.

chasemp lowered the priority of this task from Unbreak Now! to High.Oct 31 2018, 7:50 PM
chasemp added a subscriber: chasemp.

with https://phabricator.wikimedia.org/T204016#4693413 lowering this, maybe it can even be resolved?

MaxSem added a comment.Nov 2 2018, 7:05 PM

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

chasemp claimed this task.EditedNov 2 2018, 7:09 PM

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

thanks for the reminder, need to figure out what's going on here but for now 'unassigned' :)

note to future self, this can be resolved

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

MaxSem added a comment.Nov 6 2018, 8:57 PM

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 &lt;https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce&gt; 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.

chasemp moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Nov 14 2018, 8:26 PM
MaxSem closed this task as Resolved.Nov 14 2018, 8:30 PM
MaxSem claimed this task.

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

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