On Thu, Jan 12, 2012 at 5:57 PM, Chad innocentkiller@gmail.com wrote:
On Thu, Jan 12, 2012 at 11:51 AM, Daniel Barrett danb@vistaprint.com wrote:
Me:
Our MediaWiki:common.js stopped running on the login page. Irealize this was a security fix; it just took me by surprise. Fixed by writing a custom extension using the hook UserLoginForm to inject the few lines of JS we needed, and I'm evaluating other non-JS solutions for more security.
Chad writes:
This hasn't changed any time recently as far as I can tell...we've had
this
in place for quite awhile.
Thanks Chad. FYI, MediaWiki:common.js definitely runs on
Special:UserLogin in 1.17.1, the immediately previous release.
DanB
Hrm...I distinctly remember user's personal JS was disabled on that page. I wonder if ResourceLoader by grouping the JS also ends up disabling it. In either case, it is a security issue and there's not much we can do about it right now.
-Chad
You're both right. It's basically for ever that those special pages call OutputPage::disallowUserJs().
In 1.18 Happy-melon implemented something I think we should've had a long time ago, proper origin recognizition on a module/script level. So it is known about each module where it comes from and to what extend it should be trusted or not.
When rewriting security implementation from the basic "OutputPage::disallowUserJs" to this more elaborate way (using ORIGIN constants defined in the ResourceLoader class) it was probably (unconsciously?) switched from just "JS by users", to "modules (js/css) by origin <= site" (which also matches user JS).
I'm not sure if that's how it happened, but that what I remember and it was kept.
Krinkle