Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Page MenuHomePhabricator

Trying to create entities via wbeditentity when blocked should not assign a fresh entity ID
Closed, ResolvedPublic

Description

As an admin I want to be able to block users and not have them be able to assign new entity ids in order to avoid large gaps in entity id assignments

Problem: When a user is blocked, using wbeditentity in an attempt to create a new item / property will still end up with that item / property ID being assigned by Wikibase (though it is never used)

Screenshot & Example:

image.png (149×1 px, 33 KB)

In the screenshot (from test.wikidata.org) when testing the green line is where the issue occurs:

  • Item ending in 29 was created by Addshore
  • Lydia was blocked
  • Lydia tried creating an item using wbedtientity API
  • Lydia was unblocked
  • Lydia tried creating another item (succeeded ending in 31)
  • the item ending in 30 was skipped.

The API call used to attempt the creation was:

https://test.wikidata.org/wiki/Special:ApiSandbox#action=wbeditentity&format=json&new=item&data=%7B%7D

BDD
GIVEN a user is blocked
WHEN that user tries to create an entity via wbeditentity
THEN no entity ID should be assigned

Acceptance criteria:

  • When a user tries to create a new entity via wbeditentity (item or property) and they are blocked, then a new ID should not be assigned.

Original report

When somebody is blocked and they try to create a new item, save is not possible but wb_id_counters table is updated, therefore a Qid is lost permanently. This may be an abuse potential (creating higher database load) for malicious users with no way either to detect or to stop on wiki. Ideally no Qid should be assigned if the save is not possible (also when label/description conflict, invalid entity data, etc).

Event Timeline

A cause for this problem might be, that in the last few days some indexes are updated not immediately, but with a delay of some days.

For example the result of this

https://petscan.wmflabs.org/?language=de&project=wikipedia&categories=Wikipedia:Artikel%20ohne%20Wikidata-Datenobjekt%0D%0A&negcats=Wikipedia%3AL%C3%B6schkandidat&combination=union&ns%5B0%5D=1&show_redirects=no&wikidata_item=without&interface_language=en&&doit=

Petscan Query should show only articles without wikidata objects.

In the last days, also entries are shown, where the articles already have been connected to a (new or existing) wikidata object.

It's true that IDs may be "swallowed" by unsuccessful attempts to create an item. But I don't see this as a problem. The IDs have no significance, they could just as well be chosen randomly instead of sequentially. The ID system may well be changed to something else entirely at some point, e.g. GUIDs.

I want to thank you for reporting this anyway, because it *might* have been an indication for Something Bad happening, like items just vanishing without a trace. But I don't see any evidence of that. So, closing WONTFIX.

This is already posted on wiki, but also post here for reference:
Allocating one ID requires one read and write of wb_id_counters table. It is possible that some malicious users doing a large number of failed creation, which may significantly increase the database load. What's worse are 1. There are no ways on wiki to find out users who are doing failed item creation and 2. Blocking the user does not solve the issue as IDs will still be allocated.

Before T213817: Use separate DB connection for (Sql/UpsertSql)IdGenerator in Wikibase is fixed, things are even much worse, as there was a DoS potential: malicious users can produce many database errors (logspam), or even impede others creating new entities.

Addshore renamed this task from Checking whether save is possible before assigning Qids to Trying to create entities via wbeditentity when blocked should not assigned a fresh entity ID.Sep 22 2020, 10:24 AM
Addshore updated the task description. (Show Details)

Not only for blocked, but also for label/description conflict, AbuseFilter and rate limit.

hoo renamed this task from Trying to create entities via wbeditentity when blocked should not assigned a fresh entity ID to Trying to create entities via wbeditentity when blocked should not assign a fresh entity ID.Sep 23 2020, 2:02 AM
hoo claimed this task.

Change 630979 had a related patch set uploaded (by Hoo man; owner: Hoo man):
[mediawiki/extensions/Wikibase@master] Don't allocate entity ids for users that can't edit

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

The scope of this task is a bit wider than the patch. If an item can not be created because of an label/description conflict, the ID is still allocated. Therefore the issue described in T232620#6456047 still exists and there are no way to detect this.

Other circumstances that item creation will fail may include rate limit, abusefilter and malformed entity content.

The scope of this task is a bit wider than the patch. If an item can not be created because of an label/description conflict, the ID is still allocated. Therefore the issue described in T232620#6456047 still exists and there are no way to detect this.

Other circumstances that item creation will fail may include rate limit, abusefilter and malformed entity content.

This task specifically is only about blocks, the other issues will require different strategies to fix (and that will be much more involved because currently Wikibase assumes the id to be set during all of these things).

My task originally said "Checking whether save is possible before assigning Qids". Should I file a new task for these other issues?

@Bugreporter yes, please open a new task for these issues.

How to test locally:

first verify on master - block yourself, then execute api.postWithEditToken( { action: 'wbeditentity', new: 'item', data: '{}' } ) in your developer console
no new item will be created, but each time you do it, your wb_id_counters will be updated:

MariaDB [wikidatawiki]> SELECT * FROM wb_id_counters;

And once you check out the patch that should no longer happen

Change 630979 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Don't allocate entity ids for users that can't edit

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

Adam and I just tried it on test.wikidata.org and IDs are no longer skipped when blocked users create Items.
\o/

Change 744799 had a related patch set uploaded (by Tobias Andersson; author: Hoo man):

[mediawiki/extensions/Wikibase@REL1_35] Don't allocate entity ids for users that can't edit

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

Change 744799 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@REL1_35] Don't allocate entity ids for users that can't edit

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