Page MenuHomePhabricator

Allow loading gadget module by URL query parameter
Open, LowestPublic

Description

Inspired by the "withJS-url parameter"-script floating around various wikis (which calls importScript() if the passed pagename is in the MediaWiki:-namespace), I think such functionality would qualify as core functionality.

For backwards compatiblity and to avoid any security issues on wikis which use the MediaWiki:-namespace on a less-than-sysop security level, this should be disabled by default, and enableable with a wiki global (eg. $wgAllowWithModuleLoading=true;)

However given how the resourceloader currently works and how it will/may work in the future [1].
I think it's best not to implemenent the script as it is now on those wikis, instead I've made this bug depend on bug 27535 ( registering wikistyles and wikiscripts as part of a module ), and propose to make the parameter someting like withModule.

Example:

That way it can be used to load CSS as well, since CSS can be (part of) a module.

This also stops the need to create mini-scriptpages in the MediaWiki:-namespace that would call importScript() and importStylesheet() several times (once for every css/js part of the module) in order to make it work with the withJS-hack.

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:27 PM
bzimport set Reference to bz27766.
bzimport added a subscriber: Unknown Object (MLST).

(In reply to comment #0)

However given how the resourceloader currently works and how it will/may work
in the future [1].

Do you still remember what [1] was supposed to mean?

What are the new plans for this, considering that T29535: Add support for loading wiki pages as scripts/styles in ResourceLoader was closed (and T27845: Support loading wiki pages through mediaWiki.loader.load() and T29281: Add support in the front-end for loading wiki pages as resources are open)?

Krinkle claimed this task.
Krinkle updated the task description. (Show Details)
Krinkle set Security to None.
Krinkle removed a subscriber: wikibugs-l-list.
Krinkle renamed this task from Add configuration option to enable loading modules based on url parameter to Allow loading modules by on request url query parameter.Apr 17 2017, 11:39 PM
Krinkle renamed this task from Allow loading modules by on request url query parameter to Allow loading modules by request url query parameter.
Krinkle reopened this task as Open.
Krinkle removed Krinkle as the assignee of this task.

As long as any implementation honours page restrictions surrounding module origins, I'm okay with this. (E.g. Special:Login?withModule=site will not work). There's no need to make this configurable imho.

Krinkle lowered the priority of this task from Medium to Lowest.Aug 18 2018, 6:11 AM
Krinkle moved this task from Limbo to Watching on the Performance-Team (Radar) board.

Moving to radar as we're not likely to work on this at any point. Patches welcome, though.

I don't see this as something that needs to be part of core and am less sure if we'd accept it as patch nowdays. It's still require maintenance and non-trivial security considerations in terms of being able to load code in code in unanticipated places.

The original request is for gadgets, which are currently enabled only in site-wide fashion (until T63007). I'll narrow the scope of this ticket to just that part of it, which would be less problematic, and imho a more natural fit in the product roadmap. There's a clear use case for it, and I think it would be something a maintainer of Gadgets would get to eventually and might also accept patches for before that.

Krinkle renamed this task from Allow loading modules by request url query parameter to Allow loading gadget module by URL query parameter.Oct 8 2021, 5:53 PM

Change 730684 had a related patch set uploaded (by SD0001; author: SD0001):

[mediawiki/extensions/Gadgets@master] Allow loading gadget module by URL query param

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

I'm copying in the Security team to give this a lookover as well. As it stands this would be supported on all index.php contexts regardless of wiki visibility/configuration or logged-in state (e.g. private wikis will run the code when visited by someone who received such a crafted link), namespace (incl special pages for blocking users, wikidata, articles, and file pages), or page action (e.g. view page, page history, edit mode, delete/undelete, etc.).

I'm copying in the Security team to give this a lookover as well. As it stands this would be supported on all index.php contexts regardless of wiki visibility/configuration or logged-in state (e.g. private wikis will run the code when visited by someone who received such a crafted link), namespace (incl special pages for blocking users, wikidata, articles, and file pages), or page action (e.g. view page, page history, edit mode, delete/undelete, etc.).

Thanks for flagging this - we had a chat about this at the Security-Team clinic this morning. From what we can tell, this functionality would really only provide an additional layer of convenience and maybe abstraction for an attacker to exploit, as similar functionality can already be accomplished via importScript() and importStylesheet() (as the task description notes) and any modules would be loaded from pages within the theoretically more trusted MediaWiki: namespace. In this case, from a security perspective, we'd likely rate this as low risk, unless there are some additional concerns here that we're not understanding.