On Thu, Jan 12, 2012 at 11:00 PM, Daniel Friesen
On Wed, 11 Jan 2012 14:09:23 -0800, Chad
On Wed, Jan 11, 2012 at 4:43 PM, Happy Melon
Yes, no user-editable scripts are run on pages
where password forms
because it is trivially easy for users to use them to introduce
password-sniffing JS attacks, either deliberately or inadvertantly. Or
that's the idea, at least; IIRC there's an open bug about gadgets
somewhere they probably shouldn't, etc.
Yep, you're looking at bug 10005. This applies to password reset
preferences (last I checked) and user login.
That bug appears to be about user-js.
I used to be in the camp that wanted scripts to not be run on login pages
for security, and opposed ajax logins on the grounds that scripts would be
run on the page.
But awhile ago I learned about the history.pushState api. I found that
it's almost pointless to hide scripts exclusively from pages with password
forms on them. Since if a script is run on 'any' page on the wiki it's
possible to use xhr and pushState together to fake the entire page
browsing functionality, including the address bar changing as if you
actually went to the url. So it's possible to hijack the native page
browsing and make it look like the user went to the user login page when
in reality the page never changed, the whole login page was actually
loaded by xhr, and the malicious script is still running ready to swipe
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name
Just to point it out explicitly, scripts are not and never were hidden
from any page in MediaWiki (at least not for 5+ years).
OutputPage decides what the "trust" level of queued modules must be for them
to be loaded. SpecialUserLogin and others raise this from the default
to "not site and below". Leaving only core and extensions.
is core or extension. I believe a few ajax logins have been floating around
the net in the
I agree the thought behind it getting dated though. Aside from the malicious
way of faking the user front, one can actually make calls to the API from