Page MenuHomePhabricator

Restrict editing of .json pages in the user namespace (like .js and .css)
Closed, ResolvedPublic

Description

Users currently have special protected for their personal .js and .css pages. The protection entails that only they can create or edit them, with the exception of privileged users holding the edituserjs or editusercss user right.

There are currently users storing private "nobody else edits this" kind of stuff on .js pages in order to receive this protection, even when said content is not JavaScript code.

There are even tools (Toolforge tools, Gadgets, user scripts, standalone apps) that encourage or require the storing of non-js content on a specially named .js sub page.

This use case is blocking T76204, which wants to give users a way to automatically validate their user scripts against common errors.

Per T76204#802378, and more generally, we should provide users with the option to store data (in the JSON format) under their user space with the same protection level as .js and .css pages currently receive.

In addition to being able to unblock T76204, by providing tools with a way to migrate their data, it is also more generally a useful feature for storing personal data. Some of which could be used in the future for storing other kinds of site customisations.

Event Timeline

Krinkle created this task.Dec 3 2014, 1:33 AM
Krinkle updated the task description. (Show Details)
Krinkle raised the priority of this task from to Lowest.
Krinkle changed Security from none to None.
Krinkle added a subscriber: Krinkle.

Change 177172 had a related patch set uploaded (by Krinkle):
content: Recognise .json as JsonContent User and MediaWiki namespace

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

Patch-For-Review

TTO added a subscriber: TTO.Dec 3 2014, 9:33 AM
Rillke added a subscriber: Rillke.Dec 3 2014, 9:48 AM
Se4598 added a subscriber: Se4598.Dec 3 2014, 1:26 PM

Change 177172 merged by jenkins-bot:
content: Recognise .json as JsonContent in User and MediaWiki namespace

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

Jdforrester-WMF raised the priority of this task from Lowest to Normal.Jun 3 2015, 4:33 PM
Jdforrester-WMF assigned this task to Krinkle.
Jdforrester-WMF added a project: User-notice.

Does the above patch restrict editing of user-json? I guess not? Do we need to add a new user right for this, and tweak the language about the existing right (editusercssjs) to mention JSON too?

Krinkle added a comment.EditedJun 3 2015, 4:47 PM

Does the above patch restrict editing of user-json?

No, this patch is a prerequisite for that.

Krinkle lowered the priority of this task from Normal to Low.Feb 9 2016, 7:16 PM
Krinkle removed Krinkle as the assignee of this task.Jul 16 2016, 1:27 AM

@Legoktm, thanks!
@Krinkle, hello, any progress here?

Does this function account for content model changes?

Does this function account for content model changes?

What do you mean?

What I mean is that changing the content model of a JS page causes it to lose its protection; see links in T85847#2959070

Nirmos added a subscriber: Nirmos.Feb 6 2018, 8:19 AM

Change 408940 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@master] [WIP] Add protection for User: and MediaWiki: JSON pages

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

What I mean is that changing the content model of a JS page causes it to lose its protection; see links in T85847#2959070

The code currently stops a third party editing a user's page if it's a subpage with the JS or CSS content model; it doesn't actually depend on being called .js or .css, but that's the only way non-admins can make a JS/CSS content model page. With this change, it would also extend to the JSON content model (and the .json extension), yes. The particular issue you highlighted would no longer break – User:Foo/bar.json pages (or User:Foo/bar.js with the JSON content model) would not be editable by other users except admins.

Krinkle updated the task description. (Show Details)Mar 29 2018, 2:27 AM

Thank you for the task description expansion!

Change 408940 merged by jenkins-bot:
[mediawiki/core@master] Add protection for User: JSON pages in the same manner as JS & CSS ones

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

Jdforrester-WMF closed this task as Resolved.Mar 29 2018, 2:51 PM
Jdforrester-WMF removed a project: Patch-For-Review.
Jdforrester-WMF claimed this task.

Hello! I see many good reasons for this change, but perhaps this wasn't brought up: Some bots use JSON config pages that are intentionally open for anyone to edit, for example https://en.wikipedia.org/wiki/User:Community_Tech_bot/Popular_pages_config.json

For our use case, we'd have to change the content model to wikitext so that anyone could edit it. This is fine except you then don't have the nifty JSON editor that validates your input, nor the pretty JSON formatting when viewing the page directly.

Would it make sense to allow admins to lower the protection level? I assume adding this functionality wouldn't be a trivial change. I'm just curious if you at all think it is a good idea.

Additionally, now when viewing a JSON page, it shows the same warnings at the top that JS/CSS pages do:

Depending on what's using the JSON, these could be true, but they certainly aren't in our case. It's just misleading, is all.

Some bots use JSON config pages that are intentionally open for anyone to edit, for example https://en.wikipedia.org/wiki/User:Community_Tech_bot/Popular_pages_config.json

Couldn't that page be moved to another namespace, like Project:, and change the content model there to json?

Hello! I see many good reasons for this change, but perhaps this wasn't brought up: Some bots use JSON config pages that are intentionally open for anyone to edit, for example https://en.wikipedia.org/wiki/User:Community_Tech_bot/Popular_pages_config.json

For our use case, we'd have to change the content model to wikitext so that anyone could edit it. This is fine except you then don't have the nifty JSON editor that validates your input, nor the pretty JSON formatting when viewing the page directly.

You could move it to the Project namespace? In general, asking users to edit JSON isn't ideal.

Would it make sense to allow admins to lower the protection level? I assume adding this functionality wouldn't be a trivial change. I'm just curious if you at all think it is a good idea.

I think this opens up a can of worms.

Additionally, now when viewing a JSON page, it shows the same warnings at the top that JS/CSS pages do:

  • Code that you insert on this page could contain malicious content capable of compromising your account. (MediaWiki:Jswarning)
  • The code will be executed when previewing this page. (MediaWiki:Jswarning)
  • After saving, you have to bypass your browser's cache to see the changes. (MediaWiki:Clearyourcache)

    Depending on what's using the JSON, these could be true, but they certainly aren't in our case. It's just misleading, is all.

Could you file a separate bug for that?

Some bots use JSON config pages that are intentionally open for anyone to edit, for example https://en.wikipedia.org/wiki/User:Community_Tech_bot/Popular_pages_config.json

Couldn't that page be moved to another namespace, like Project:, and change the content model there to json?

Yes, that's what I'd recommend if you really do want anyone (not just sysops) able to redirect the work of an automated tool.

I'd like to echo what @MusikAnimal wrote above about lowering the protection level. An alternate could be to not have this apply on bot account pages.
I'm surprised this change went through without a wider announcement ahead of rollout.

I'd like to echo what @MusikAnimal wrote above about lowering the protection level.

OK. But implementing that would be a serious amount of work, and not generally a good idea from a product perspective (yet more complication in an area that already confuses many sysops).

An alternate could be to not have this apply on bot account pages.

As above, this sounds like a bad idea to provide a hack that shouldn't exist.

I'm surprised this change went through without a wider announcement ahead of rollout.

Discussed for multiple years, announced in Tech/News, highlighted in Scrum of Scrums at least twice over the years. If anything, rather more announcement than something this mild deserves.

I'm surprised this change went through without a wider announcement ahead of rollout.

Discussed for multiple years, announced in Tech/News, highlighted in Scrum of Scrums at least twice over the years. If anything, rather more announcement than something this mild deserves.

Not everyone's been around for years. That bot came into existence last year.
I don't see a mention in the recent few scrum of scrums notes but I didn't look too closely.

Couldn't that page be moved to another namespace, like Project:, and change the content model there to json?

You could move it to the Project namespace?

Given the nature of our bot, I think we could get away with this. However on enwiki anything in the WP namespace is usually subject to scrutiny, so other bot operators probably will have trouble storing their config pages there. I realize this probably won't be an issue some 90-something percent of the time, as any given bot config is rarely edited. It was just really neat that we could allow non-admins to make configuration changes.

In general, asking users to edit JSON isn't ideal.

In general, yes. The old Popular Pages Bot had a full-on wiki-like interface on Toolforge, such that any changes can be audited. The community asked that we replicate this functionality, and instead of building a whole new tool we opted for an on-wiki config page since it offers a revision history.

Additionally, now when viewing a JSON page, it shows the same warnings at the top that JS/CSS pages do

Could you file a separate bug for that?

Created at T194086

For now we will try to move the Popular Pages Bot documentation and config to the WP namespace. Thanks!