Page MenuHomePhabricator

ContentTranslationPublishRequirements does not always prevent unqualified user from publishing translation
Closed, DuplicatePublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

  • Navigate to a wiki that set ContentTranslationPublishRequirements and where you're not in a required usergroup.
  • Start a new translation or open an existing one.
    • If opened an existing translation, please ensure the target is set to "new page" and not "personal draft" and exit and go back to the translation.
    • If required, type something so that you'll not create an empty article.
  • Click Publish.

What happens?:
The article is published even though you shouldn't be able to do that.

What should have happened instead?:
The user should be presented with an information that only more experienced users can publish translations directly.

Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):

Other information (browser name/version, screenshots, etc.):
When changing the target place, the user is forbidden to publish to mainspace. But after exiting the translation interface and coming back it's possible again to publish.

I've recorded the bug reproduction. There appears a warning about the source being outdated but it has no influence on the bug presence.

I've noticed the bug on plwiki after deploying T362756: [plwiki] Limit Content Translation publishing to mainspace for non-editors, but it's also present on eg. enwiki. On some wikis an abuse filter will prevent publication in such a scenario but we should be able to exclusively rely on the ContentTranslation configuration setting for that. Such a filter would normally act on plwiki as well but for demonstration purposes I've used a special test account that's exempt from the respective filter.

Event Timeline

This may apply to wgContentTranslationUnmodifiedMTThresholdForPublish too?

We need to make sure onTranslationView() returns proper value if re-visiting translation or move out some mw.config variables from this condition.

Please note that this bug is being fixed in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ContentTranslation/+/1020221, which should be deployed next Tuesday (when the next backport/config window is available).

KartikMistry changed the task status from Open to In Progress.Apr 18 2024, 1:08 PM
KartikMistry triaged this task as High priority.

The patch that @KartikMistry mentioned was deployed on 22 April to plwiki, but it seems that it doesn't completely prevent unqualified users from publishing translations to mainspace. The edit filter for that caught two cases on 24.04. and 25.04.: https://pl.wikipedia.org/w/index.php?title=Specjalna:Rejestr_nadu%C5%BCy%C4%87&wpSearchFilter=38&uselang=en

Shouldn't the restriction be enforced in the backend? Front-end-only prevention seems like a silly and very vulnerable solution to me...

(If it helps, I can share the diff or the AF variables for that actions)

The patch that @KartikMistry mentioned was deployed on 22 April to plwiki

No, from 23 to 25. Last event was 18:20, deployments are on 20:00 (in Poland)

Shouldn't the restriction be enforced in the backend? Front-end-only prevention seems like a silly and very vulnerable solution to me...

If someone really want to ommit this... there are easier means to do that.

No, from 23 to 25. Last event was 18:20, deployments are on 20:00 (in Poland)

The change was backported to wmf.1 on Tuesday (and I'm sure I've checked it): https://wikitech.wikimedia.org/w/index.php?title=Deployments&oldid=2171928#Tuesday,_April_23

But yes, I mistaken the date - it was 23.04. and not 22.04.

They had problems T363086 with deployment procedure and I don't know how they finalized it.

They had problems T363086 with deployment procedure and I don't know how they finalized it.

The problem still persists. I've checked just now and there are filter hits from 30 April.