ApiHelp on api.php should set OutputPage::disallowUserJs
Open, NormalPublic

Description

Similar to login pages and preferences, I think this page should also set disallowUserJs() so that 'site' and 'user' modules are not loaded here.

Especially because this output context is very unlike other skins. This don't work as expected. I ran into this multiple times when dealing with wikis where site scripts were a bit broken.

Aside from making sure this neutral and light-weight context works properly without the page weight of site scripts (which don't expect to run on this page). It also makes sure the page stays safe and secure so that people can reach it to get help =even if things are broken at the moment.

Krinkle created this task.Apr 14 2016, 8:27 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 14 2016, 8:27 PM

That seems like a good thing to do.

I'm not seeing anything particularly sensitive on the page that needs protections (token is already included on most pages), so I think we could make this ticket public?

FWIW in the past we've advertised User:Foobar/apioutput.css to allow people to customize how the API help pages look, e.g. https://lists.wikimedia.org/pipermail/mediawiki-api/2014-December/003436.html

Anomie added a subscriber: Anomie.Apr 15 2016, 11:53 AM

FWIW in the past we've advertised User:Foobar/apioutput.css to allow people to customize how the API help pages look, e.g. https://lists.wikimedia.org/pipermail/mediawiki-api/2014-December/003436.html

Lego beat me to mentioning this.

I don't think "people write bad code in common.js" is all that good of a reason to disable all possibility of user customization.

I don't think "people write bad code in common.js" is all that good of a reason to disable all possibility of user customization.

Agreed, I'm not saying either of those things. The reason is not based on bad code existing in Common.js, and I'm not saying we should disable all customisation.

I'm merely saying that it's unrealistic to expect or want Common.js to work correctly on api.php. I wasn't aware of apioutput being used as a skin is more than an internal detail, and that it's a public interface for customisation. In that case we may want to consider only disabling inclusion of 'common'. Perhaps by creating a dedicated module similar to Filepage and loading that instead of site.

As long as apioutput.css (including User:Example/apioutput.css) and .js continue to work for customization, I don't see any reason to object to skipping common.css and .js for the API output.

Note both ApiHelp and ApiFormatBase (where it handles 'fm' formats) should do the same thing, whatever that thing is. The cleanest thing to do might be to have the "apioutput" skin itself handle it somehow, if that makes sense.

Talked with the rest of the Security-Team, and we're not seeing a way this can be abused. Anyone object to making this public?

Talked with the rest of the Security-Team, and we're not seeing a way this can be abused. Anyone object to making this public?

^ @Krinkle / @Anomie, any objection to making this public?

Fine with me.

Krinkle triaged this task as Normal priority.May 16 2016, 1:42 PM
Krinkle edited projects, added Security-Team; removed Security.
Krinkle changed the visibility from "Custom Policy" to "Public (No Login Required)".
Krinkle changed Security from Software security bug to None.
Bawolff moved this task from Backlog to Watching on the Security-team-backlog board.