On Thu, Jan 12, 2012 at 5:57 PM, Chad <innocentkil...@gmail.com> wrote:
> On Thu, Jan 12, 2012 at 11:51 AM, Daniel Barrett <d...@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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
