Good point. I'd say we should convert it to a JSON page (protected by default) and migrate all existing pages.

Adding Growth team members to CC to grant them access if they don't already.

In T245110#5879806, @Urbanecm wrote:

Good point. I'd say we should convert it to a JSON page (protected by default) and migrate all existing pages.

Adding Growth team members to CC to grant them access if they don't already.

Would this be at the same title, just as a JSON page, or at echo-whitelist.json?

Also has the advantage of a cleaner syntax: just a normal json array:

[
	"DannyS712",
	"Sinebot",
	"Foobar"
]

sysadmins have edituserjson, so it should be pretty straight forward for them to do

In T245110#5879819, @DannyS712 wrote:

In T245110#5879806, @Urbanecm wrote:

Good point. I'd say we should convert it to a JSON page (protected by default) and migrate all existing pages.

Adding Growth team members to CC to grant them access if they don't already.

Would this be at the same title, just as a JSON page, or at echo-whitelist.json?

Latter - to automatically be treated as JSON.

Also has the advantage of a cleaner syntax: just a normal json array:

New format

[
	"DannyS712",
	"Sinebot",
	"Foobar"
]

sysadmins have edituserjson, so it should be pretty straight forward for them to do

By default, don't ask users to use JSON or whatever that requires a sort of a syntax. Syntax is the path for the "something goes wrong" journey, even with skilled users. :)
One user per line on a blank page, as it is now, is the best we can ask.

In T245110#5890744, @Trizek-WMF wrote:

By default, don't ask users to use JSON or whatever that requires a sort of a syntax. Syntax is the path for the "something goes wrong" journey, even with skilled users. :)
One user per line on a blank page, as it is now, is the best we can ask.

If we want to keep the current structure, but protect it from others, what level of protection is desired? I would suggest requiring edituserjson (similar to above) to allow admins, etc to remove any inappropriate content while still allowing users to be safe with the knowledge that it is as protected as their json pages.
If this approach is used, we could

• Add a hook to Title::isUserJsonConfigPage
• Add a handler to EchoHooks

What is the usual standard concerning editing json files? IF any, it should be applied here to keeps things simple and logical.

If we are going to extend edituserjson to non-JSON pages, it should probably be renamed. edituserconfig would be a good name, except it conflicts with Title::is[Site|User]ConfigPage which somewhat misleadingly considers CSS/JS pages as config.
(Also, please don't make isUserJsonConfigPage return true on non-JSON pages.)

In T245110#6014142, @Tgr wrote:

If we are going to extend edituserjson to non-JSON pages, it should probably be renamed. edituserconfig would be a good name, except it conflicts with Title::is[Site|User]ConfigPage which somewhat misleadingly considers CSS/JS pages as config.
(Also, please don't make isUserJsonConfigPage return true on non-JSON pages.)

Then what about having Title::isUserConfigPage trigger a hook for extensions?

In T245110#6262200, @DannyS712 wrote:

Then what about having Title::isUserConfigPage trigger a hook for extensions?

Yeah, that seems like a reasonable thing to do.

In T245110#6262568, @Tgr wrote:

In T245110#6262200, @DannyS712 wrote:

Then what about having Title::isUserConfigPage trigger a hook for extensions?

Yeah, that seems like a reasonable thing to do.

Since this would require two patches (core to add the hook, and echo to use it), is it okay to have the core patch public, given the scope (adding a new hook) as long as we don't say why its needed?

Personally I don't see much value in making any task/patch private. There is no security issue here.

In T245110#6262570, @DannyS712 wrote:

Since this would require two patches (core to add the hook, and echo to use it), is it okay to have the core patch public, given the scope (adding a new hook) as long as we don't say why its needed?

I think this is a minor enough issue, that should be fine. I'll make the task public.

In T245110#6262636, @Tgr wrote:

Personally I don't see much value in making any task/patch private. There is no security issue here.

In a very minor way, I think it at least falls under this class of vulns. And there have been similar issues in the past: https://www.mediawiki.org/wiki/Topic:Uirl8i2lzklbbpy9.

Can the edit policy be reset too?

Realistically, I think using a wiki page for this was a quick hack and it would make more sense as a user preference long-term (rather than trying to figure out whether it should be protected...).