Page MenuHomePhabricator

Security Readiness Review For UseResource
Closed, DeclinedPublic

Description

Project Information

Description of the tool/project:
The UseResouce uses the <usescript> and <usestyle> tags to allow for the loading of JavaScript and CSS pages in the MediaWiki namespace on a per-page basis.

Description of how the tool will be used at WMF:
The extension would be used to allow loading JavaScript and their accompanying CSS files relating to certain projects to only be loaded on the pages where they are needed so they wouldn't have to be loaded on every pageview through Common.js/Common.js or the Gadgets extension.

Dependencies
None

Has this project been reviewed before?
No

Working test environment
Install like any normal MediaWiki extension (instructions). To test extension you can create a JavaScript or CSS file in the MediaWiki namespace and load it using <usescript src="FILE"> (for JavaScript) or <usestyle src="FILE"> (for CSS).

Post-deployment
No time at the time, BrandonXLF is responsible for developing and maintaining the extension.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

How does the differ from TemplateStyles?
Is there any plan to deploy this to WMF sites? just seen

How does the differ from TemplateStyles?
Is there any plan to deploy this to WMF sites? just seen

TemplateStyles only allows for the loading of CSS on a per-page basis, this extension allows for both JavaScript and CSS. Unlike TemplateStyles, the CSS is not modified to only apply to page content, so CSS loaded with this extension can apply to HTML outside of the page content (for example popups created by loaded JavaScript).

Thanks for the explanation. Interested to see the result as I could image concerns with anyone able to modify a pages raw html (which with JavaScript access I'm sure could be embedded in and modified without great difficulty.)

This seems to solve a long-standing request for the Gadgets extension T63007: Allow specifying when a gadget should load (conditional, page title, action or namespace) among others. But I think adding a separate extension for this will just add more technical debt, and we're already in a lot of debt with Gadgets. I think working on finishing Gadgets 2.0 would be a much better use of resources than trying to deploy and maintain a separate extension, if you'd be interested in working on that.

This seems to solve a long-standing request for the Gadgets extension T63007: Allow specifying when a gadget should load (conditional, page title, action or namespace) among others. But I think adding a separate extension for this will just add more technical debt, and we're already in a lot of debt with Gadgets. I think working on finishing Gadgets 2.0 would be a much better use of resources than trying to deploy and maintain a separate extension, if you'd be interested in working on that.

I already made https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/624517 (for namespaces), but there's no one maintaining the Gadgets extension to review and merge the change. Using gadgets for the use case of this extension is basically impossible since you would need to add the title of each page that uses the gadget to the gadget definition, which could be thousands of pages.

sbassett changed the task status from Open to Stalled.Feb 23 2021, 5:48 PM
sbassett triaged this task as Lowest priority.
sbassett moved this task from Incoming to Back Orders on the secscrum board.

@sbassett: Hi, what is this task stalled (waiting for further input (e.g. from the task author or a third party like upstream) and can currently not be acted on) on exactly?

@Aklapper - a number of items from the Security-Team's perspective. For starters: there's no estimated deployment date which is a hard requirement for us to schedule reviews. It also doesn't satisfy a number of requirements for higher priority or status as described within the "What type of project or code triggers this review process?" and "How are these requests prioritized?" sections of the current security readiness review SOP. There are also questions above as to whether this extension would be the best approach for the current indicated problem. Given all of that, this review will have to be very low-priority for the Security-Team. If you'd like to change the task to "Open", I guess that's fine, though it won't really change how the Security-Team currently views this task.

@sbassett: Thanks a lot for elaborating, as it helps requesters and interested folks to better understand what's blocking. Appreciated.

JBennett added a subscriber: JBennett.

The Security team is updating their readiness review SOP to reflect a new change that any request that has aged 90 days without being in a reviewable state will be declined. We do this to help keep our work area current, accurate and reflective of actual work. If the status of your project changes please re-tag us and we will get this work scheduled.

Aklapper added a subscriber: Jcross.

@Jcross: Please do not remove correct metadata as it makes it harder to find tasks. This is and was a security readiness review request (which has been declined). Thanks.