In 1.18.0, the page Special:UserLogin no longer runs the JavaScript in MediaWiki:common.js. Is this an intentional change from 1.17, and if so, is there a workaround to make custom JS run on the login page?
(I tested this by putting alert('foo') in MediaWiki:common.js. The alert appears on all articles & special pages except Special:UserLogin.)
Thank you, DanB
On 11 January 2012 21:27, Daniel Barrett danb@vistaprint.com wrote:
In 1.18.0, the page Special:UserLogin no longer runs the JavaScript in MediaWiki:common.js. Is this an intentional change from 1.17, and if so, is there a workaround to make custom JS run on the login page?
(I tested this by putting alert('foo') in MediaWiki:common.js. The alert appears on all articles & special pages except Special:UserLogin.)
Thank you, DanB
Yes, no user-editable scripts are run on pages where password forms reside, 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 running somewhere they probably shouldn't, etc.
You could probably hack around it by using one of the many hooks in the page rendering stack to add the JS module on the pages where it's not already there, but before doing so it's worth thinking about the reason why it was removed in the first place.
--HM
You could probably hack around it by using one of the many hooks in the page rendering stack to add the JS module on the pages where it's not already there, but before doing so it's worth thinking about the reason why it was removed in the first place.
Thank you HM. In our case, we are using a script for several purposes (in a private wiki behind a firewall):
* Automatically check the "keep me logged in for 30 days" checkbox.
* Remove any trailing "@companyname.com" from the username. Users in our company are accustomed to logging in this way on their Windows boxes, and we'd get several support calls per week from people who "can't log into the wiki" because they were adding @companyname.com onto their wiki usernames.
I wound up using the hook UserLoginForm to inject the JavaScript we need, via $wgOut->addScriptFile. The JS is:
$('#userloginForm form') .submit(function(e){ var $input = $('#wpName1', this); $input.val($input.val().replace(/@.*$/, '')); }) .find('#wpRemember') .attr('checked', 'checked') .end() .find('#wpName1:not([value]), #wpPassword1') .eq(0) .focus();
Is there a more secure way to do what we need on the login page (without modifying core code)?
Thanks, DanB
On Wed, Jan 11, 2012 at 3:51 PM, Daniel Barrett danb@vistaprint.com wrote:
You could probably hack around it by using one of the many hooks in the page rendering stack to add the JS module on the pages where it's not already there, but before doing so it's worth thinking about the reason why it was removed in the first place.
Thank you HM. In our case, we are using a script for several purposes (in a private wiki behind a firewall):
- Automatically check the "keep me logged in for 30 days" checkbox.
Is there a more secure way to do what we need on the login page (without modifying core code)?
rememberpassword in wgDefaultUserOptions?
On 11 January 2012 21:51, Daniel Barrett danb@vistaprint.com wrote:
- Remove any trailing "@companyname.com" from the username. Users in our company are accustomed to logging in this way on their Windows boxes, and we'd get several support calls per week from people who "can't log into the wiki" because they were adding @companyname.com onto their wiki usernames.
The way we do it on our Mantis bugtracker is to use the LDAP server for all logins. Something like that for MediaWiki would do the job too. One password!
- d.
On Wed, Jan 11, 2012 at 6:18 PM, David Gerard dgerard@gmail.com wrote:
The way we do it on our Mantis bugtracker is to use the LDAP server for all logins. Something like that for MediaWiki would do the job too. One password!
Ryan's been maintaining such a feature for years :)
http://www.mediawiki.org/wiki/Extension:LDAP_Authentication
-Chad
On 11 January 2012 23:31, Chad innocentkiller@gmail.com wrote:
On Wed, Jan 11, 2012 at 6:18 PM, David Gerard dgerard@gmail.com wrote:
The way we do it on our Mantis bugtracker is to use the LDAP server for all logins. Something like that for MediaWiki would do the job too. One password!
Ryan's been maintaining such a feature for years :) http://www.mediawiki.org/wiki/Extension:LDAP_Authentication
I know, I just didn't bother setting it up on any of ours :-)
- d.
On 11 January 2012 21:51, Daniel Barrett danb@vistaprint.com wrote:
- Remove any trailing "@companyname.com" from the username. Users in our company are accustomed to logging in this way on
their Windows boxes, and we'd get several support calls per week from people who "can't log into the wiki" because they were adding @companyname.com onto their wiki usernames.
The way we do it on our Mantis bugtracker is to use the LDAP server for all logins. Something like that for MediaWiki would do the job too. One password!
Yes, we use the LDAPAuthentication extension for MediaWiki. But usernames on the login page still must be "foo" rather than "foo@companyname.com". Hence the JavaScript to remove @.*.
DanB
On 12 January 2012 02:47, Daniel Barrett danb@vistaprint.com wrote:
On 11 January 2012 21:51, Daniel Barrett danb@vistaprint.com wrote:
- Remove any trailing "@companyname.com" from the username. Users in
our company are accustomed to logging in this way on
their Windows boxes, and we'd get several support calls per week from
people who "can't log into the wiki" because they
were adding @companyname.com onto their wiki usernames.
The way we do it on our Mantis bugtracker is to use the LDAP server for all logins. Something like that for MediaWiki would do the job too. One password!
Yes, we use the LDAPAuthentication extension for MediaWiki. But usernames on the login page still must be "foo" rather than "foo@companyname.com". Hence the JavaScript to remove @.*.
DanB
Of course, if the login form code wasn't such a swamp, there'd be a hook you could use to preprocess the usernames server-side... :-(
--HM
Of course, if the login form code wasn't such a swamp, there'd be a hook you could use to preprocess the usernames server-side... :-(
The getCanonicalName function in the auth plugins will do this. I was actually thinking of adding a hook to LdapAuthentication in that function to let users munge the name however they'd like before LdapAuthentication munges it further.
- Ryan
On Wed, Jan 11, 2012 at 4:43 PM, Happy Melon happy.melon.wiki@gmail.com wrote:
Yes, no user-editable scripts are run on pages where password forms reside, 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 running somewhere they probably shouldn't, etc.
Yep, you're looking at bug 10005[0]. This applies to password reset pages, preferences (last I checked) and user login.
-Chad
On Wed, 11 Jan 2012 14:09:23 -0800, Chad innocentkiller@gmail.com wrote:
On Wed, Jan 11, 2012 at 4:43 PM, Happy Melon happy.melon.wiki@gmail.com wrote:
Yes, no user-editable scripts are run on pages where password forms reside, 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 running somewhere they probably shouldn't, etc.
Yep, you're looking at bug 10005[0]. This applies to password reset pages, preferences (last I checked) and user login.
-Chad
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 your password.
On Thu, Jan 12, 2012 at 11:00 PM, Daniel Friesen lists@nadir-seen-fire.comwrote:
On Wed, 11 Jan 2012 14:09:23 -0800, Chad innocentkiller@gmail.com wrote:
On Wed, Jan 11, 2012 at 4:43 PM, Happy Melon happy.melon.wiki@gmail.com wrote:
Yes, no user-editable scripts are run on pages where password forms reside, 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 running somewhere they probably shouldn't, etc.
Yep, you're looking at bug 10005[0]. This applies to password reset pages, preferences (last I checked) and user login.
-Chad
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 your password.
-- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Just to point it out explicitly, scripts are not and never were hidden completely 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 "anything" to "not site and below". Leaving only core and extensions.
So JavaScript enhancements on the login page would work fine, as long as it's origin is core or extension. I believe a few ajax logins have been floating around the net in the past already.
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 any page, directing.
Krinkle
wikitech-l@lists.wikimedia.org