Last modified: 2014-07-24 18:39:19 UTC
The userlogin page does disable the MediaWiki:Common.js and so on down to the the user's javascript. However if a user has selected gadgets using specialprefs and re-visits the userlogin page after logging in (perhaps to switch to their other-other account :p) a malicious gadget could go south with the password, just as easily as it could on the specialprefs page where on-wiki javascript is disabled for (I thought) the same concern.
Changing product/component to MediaWiki extensions/Gadgets since that's the Gadgets that should check $out->isUserJsAllowed() in wfGadgetsBeforePageDisplay().
$out->isUserJsAllowed() always returns false for the cirtical pages, which is good. But it also returns false if $wgAllowUserJs is false, which is bad. it would mean that Gadgets don't work on wikis with user JS disabled. Gadgets are more like site JS, not so much like user JS. So, $out->isUserJsAllowed() does not seem to be the right function to call. The only alternative I see is to add more hard-coded checks in the gadgets extension. Which also sucks. Ideas?
fixed in r64670 by adding hard-coded checks for Special:Userlogin and Special:Resetpass. Leaving a nicer solution for later.
> Gadgets are more like site JS, not so much like user JS. So, > $out->isUserJsAllowed() does not seem to be the right function to call. I guess you could add something like $out->isWikiJsAllowed() which is basically: > /* do we load js from a wiki page under any circumstance */ > return $wgAllowWikiJs && !($title->isCriticalPage()); And $out->isUserJsAllowed() would then become: > return $wgAllowUserJs && $out->isWikiJsAllowed(); In any case I was had hoped r64670 would be a candidate for expedited scapping.
i don't know how new it is, but it just occurred to me that [[Special:Changepassword]] is now a separate page (!) so we'll want to disable gadgets there too.
Should we perhaps not have custom js/css on any special pages then white-list the ones it should be available?
> Should we perhaps not have custom js/css on any special > pages then white-list the ones it should be available? that seems a little rash as most of the js i've written and used has been to enhance the functionality of special pages. pages which leave the server while already containing any element like <input name="wpPassword"> should refrain from loading on-wiki javascript. seems like a no-brainer. yeah, no solution is perfect, and a password prompt could be added in post-production to potentially any page byOnloadHook orCrook but i'd more likely suspect something is amiss than remit my password for no apparent reason.
I would agree with p858snake, that white listing instead of blacklisting would be a better solution.
Nicer implementation dones in r81524.
