On Thu, Jan 12, 2012 at 5:57 PM, Chad <innocentkiller(a)gmail.com> wrote:
On Thu, Jan 12, 2012 at 11:51 AM, Daniel Barrett
<danb(a)vistaprint.com>
wrote:
Me:
>> 8. Our MediaWiki:common.js stopped running on the login page. I
realize 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