MediaWiki talk:Common.js/Archive 18

Archive 15

Archive 16

Archive 17

Archive 18

Archive 19

Archive 20

→

Archive 23

Always secure Wikipedia

proposal it so add

if(wgServer == 'https://secure.wikimedia.org')
importScript( 'MediaWiki:Common.js/secure.js')

This changes any http links to interwiki or diffs on a page to links for the secure server. The script is originally User:Anakin101/alwayssecurewikipedia.js. —TheDJ (talk • contribs) 20:45, 17 January 2010 (UTC)

Go for it, imo. If you're on the secure wiki, you should stay there until you leave it, not because you've clicked a random link. Ale_Jrb^talk 20:56, 17 January 2010 (UTC)

I found issues and suggestion with the script http:\/\/([^\/]+?)\. should be http:\/\/([^a-z0-9\-]+?)\., change (page ? page : 'wiki/') to (page || 'wiki/'), \/? is unnecessary since browser automatically add this in (I think), if (sub === undefined) continue; seems to be in the wrong place. There one question, should this be supporting old links? Wikibooks use to be en.wikibook.com (no s), wikipedia.com/wiki/ redirects to the English Wikipedia, meta-wiki was meta.wikipedia.org. — Dispenser 07:43, 18 January 2010 (UTC)

I wouldn't rely on all browsers always appending a slash to URLs like http://en.wikipedia.org. Better to be safe than sorry. However, I don't think the script as written will correctly handle such valid (or at least working) URLs as http://en.wikipedia.org?title=Foo. To fix it, you could replace "\/?(.*)$" with e.g. "(\/[^?#]*|)([#?].*|)$" in the regexps and append the value of m[4] to the fixed URL unconditionally. Also, there should be some way (e.g. setting window.disableSecureLinks=true in their monobook/vector.js) for users to turn this script off if they don't want it.

Anyway, the one problem we can't fix is that one could still end up back on the insecure site in two clicks via another Wikimedia project which doesn't run this script. That's why I wrote my version as a Greasemonkey user script. Of course, merely fixing things like diff links to en.wikipedia.org itself would probably be worth having this for. —Ilmari Karonen (talk) 16:36, 18 January 2010 (UTC)

Yes please add it, we need something like this. And here's some notes and links:

• The discussion that led to this: Wikipedia:Village pump (technical)#Interwiki/interlanguage links not changing to secure. (Will later end up in /Archive 69 or 70.)
• Wikipedia:Secure server and its talk page.
• {{sec link auto}} – The current clumsy solution that we use in some places like the main page and some system messages. (I coded it, so I can call it clumsy. :))

When I created {{sec link auto}} I also tested User:Anakin101/alwayssecurewikipedia.js. I noticed that the script doesn't handle all the cases that {{sec link auto}} handles. I'll see if I can dig up my notes or do the tests again, but here's what I remember:

• I think it doesn't handle all the projects listed at Wikipedia:InterWikimedia links, especially it didn't handle links to oldwikisource:. "Old Wikisource" still handles many of the Wikisource languages, so it isn't really "old".
• And it doesn't handle cases like wikt:pt:São Paulo the way I think they should be handled. The script sends you to the English Wiktionary with a secure link, then it lets Wiktionary resolve the "pt:" part to take you to the Portuguese Wiktionary, which sends you to the normal servers. {{sec link auto}} instead resolves both the "wikt:" and "pt:" parts and gives you a secure link directly to the Portuguese Wiktionary. Although I cheat in {{sec link auto}}, I let the humans manually feed "lang=pt" so my template doesn't need to know the site matrix.

I'm sorry that I don't know enough javascript, so I can't help out with the code. But taking a look at {{sec link auto}}, or more specifically its sub-template {{sec link/secure url}} might give you some useful hints about what to resolve.

--David Göthberg (talk) 17:48, 18 January 2010 (UTC)

I have made a whole set of improvements. Many more types of links should now be recognized (at least all valid links in User:TheDJ/Sandbox2). Feedback welcome. —TheDJ (talk • contribs) 21:31, 18 January 2010 (UTC)

This seems reasonable to me to implement. I wish there were a way for this to be implemented into core MediaWiki, but that doesn't seem very possible due to parser cache issues (at least for the time being). --MZMcBride (talk) 00:30, 19 January 2010 (UTC)

 Done code deployed. —TheDJ (talk • contribs) 20:44, 21 January 2010 (UTC)

JavaScript Loading

Up in the "WikiMiniAtlas" discussion it was mentioned that "(All our other special scripts are only loaded when needed.)." I'm getting ready to implement a lot of JavaScript on my Wiki and I was just curious if this was simply a reference to doing a quick getElementById existence check in addOnloadHook for each script, or if there is some other system in place that I don't know about. I'm basically just trying to make sure that if I have 100 scripts, I don't have to do 100 checks on every page load to see if any of them apply to that page.
--Cogniac (talk) 18:11, 29 January 2010 (UTC)

simply a reference to doing a quick getElementById existence check would be my answer. But there is a more advanced scriptloader system in the making by Michael Dale. Check the Wikitech mailing list archives for details.
--Dschwen 20:43, 29 January 2010 (UTC)

I tracked this down to here: http://www.mediawiki.org/wiki/JS2_Overview in case anyone else is interested. They seem to be developing this for the upcoming 1.16 release.
--Cogniac (talk) 19:16, 4 February 2010 (UTC)

Proposal to add "withJS" feature to Common.js

Wikimedia commons has the following function in their MediaWiki:Common.js. This is useful for doing feature preview links like timed text preview. Any objections to adding the following?

/** &withJS= URL parameter *******
 * Allow to try custom scripts from MediaWiki space 
 * without editing [[Special:Mypage/monobook.js]]
 */
var extraJS = getParamValue("withJS");
if ( extraJS && extraJS.match("^MediaWiki:[^&<>=%]*\.js$") ) {
  importScript(extraJS);
}

mdale (talk) 22:42, 4 February 2010 (UTC)

Its usage will probably be pretty limited, since for security reasons it seems to be limited to only load scripts from the MediaWiki space. I think I slightly agree with this addition, but I have doubts since its usage is so limited and the code will be loaded by all users and most of those that "need" this functionality can just as well edit their personal /monobook.js. Although I see that this function can be useful for demonstration purposes when testing new scripts.

Platonides isn't the maintainer here, unless you have asked him. Here's a cleaned up version of the code: ( above )

Could someone who understands the code in the .match() part check what that code means and that it only allows loading scripts from MediaWiki space?

--David Göthberg (talk) 16:17, 5 February 2010 (UTC)

Is alert() preferred to a silent failure? --MZMcBride (talk) 16:35, 5 February 2010 (UTC)

I think the alert is useful, but not especially necessary. The alert is only shown when an invalid script name like "User:Example/myscript.js" is used. Unfortunately the alert does not show if the name is a correct but non-existing MediaWiki file name, then it silently fails which is slightly confusing.

But MZMcBride has a point. This will probably be a seldomly used function and all users always load those lines of code, so let's remove the alert to save some lines of code. I have updated my above code.

And I have read up on regular expressions and done some testing, the code in the .match() part does exactly what it should.

--David Göthberg (talk) 17:08, 5 February 2010 (UTC)

I agree with the removing the alert ( its of little value ). If people are happy with it in its present form I suggest a maintainer of Common.js plops it in there. ( I have updated the discussion to just focus on the recommended code addition) --mdale (talk) 22:28, 6 February 2010 (UTC)

I have no problem with this. I can deploy it tomorrow when I get back home, or someone else can do it in the meantime. —TheDJ (talk • contribs) 13:03, 7 February 2010 (UTC)

any updates on this? --mdale (talk) 17:39, 10 February 2010 (UTC)

I have now deployed this code. Thanks for the watchlist bump :D —TheDJ (talk • contribs) 18:15, 10 February 2010 (UTC)

OK, that was not fun. I'm so used to getParamValue being available (either trough commons or Navigation popups) it didn't occur to me it would be missing. For now I have deployed a getURLParamValue(), since i wasn't sure about potential conflicts with other tools that have their own getParamValue. I think those implementations are pretty consistent, but I'll want to run a check on that before using that name in Common.js. In the future we can use ParseURI, once the new JS2, jquery and mwEmbed tools are finally fully deployed, but that is not an option at this time of course. —TheDJ (talk • contribs) 18:49, 10 February 2010 (UTC)

Potential security issue

While, I'm sure that whoever runs http://toolserver.org/~para/geoip.fcgi is perfectly trustworthy it seems like a very weak link in the chain. Whereas scripts from Wikipedia have high cache values, publicly viewable edit histories, and notify many people when they are modified; making it likely that malicious changes can be reverted without too much damage; a modification to this script could pass unnoticed for quite some time. Are there any mechanisms in place to prevent this being horribly abused? Conrad.Irwin (on wikt) 22:55, 4 February 2010 (UTC)

As you say, the assumption that toolserver users are trustworthy. Javascript is by its very nature a potential security issue. Happy‑melon 23:45, 4 February 2010 (UTC)

It's not as if we allow just any external script to be included. So far those are only WikiMiniAtlas and the geolocating script. Those are maintained by trusted users on the toolserver. Users who have been around for a LONG time and who are not likely to go rogue. But it's like Happy-Melon says. —TheDJ (talk • contribs) 13:01, 7 February 2010 (UTC)

It took me some searching to find out what this is about, so in case anyone else is wondering: That toolserver script is called from the beginning of MediaWiki:Common.js/watchlist.js, the result of that then seems to be used in MediaWiki:Geonotice.js to display some watchlist notices only in some parts of the world. A little more searching turned up Wikipedia:Geonotice. (I have now added a code comment to watchlist.js and a page notice to Geonotice.js explaining what it is.)

--David Göthberg (talk) 01:00, 5 February 2010 (UTC)

hasClass

The hasClass function...variable...thing uses some fairly advanced JavaScript that I'm just trying to figure out. I'm assuming that the reason it is set up as a variable and not just straight "function hasClass(className)" is part of the caching optimization. But I'm not getting how it basically amounts to "var hasClass = ()();" with stuff happening inside the first pair of parentheses. I have no idea what the deal is with the two pairs of parentheses or why it relies on an anonymous function inside an anonymous function to do the work, and I'm looking for a basic explanation, if anyone would be so kind.
--Cogniac (talk) 21:19, 12 February 2010 (UTC)

The outer anonymous function, which is immediately called, creates a "global" variable reCache and returns another function which is assigned to the name hasClass. Due to JavaScript's scoping rules reCache is now only accessible from hasClass, but it's value still persists over multiple invocations of hasClass.
—Ruud 15:37, 13 February 2010 (UTC)

I understand that it's a prime example of JavaScript closures, but what I truly don't understand is the second set of parentheses at the end. I have no clue why those are necessary and/or don't break everything. I can't find any JavaScript construct that requires such a thing.
--Cogniac (talk) 20:49, 16 February 2010 (UTC)

It's a plain function call (of the outer anymous function). So hasClass is equal to the return value of the outer function (which happens to be the inner function). Without that call hasClass would be a reference to the outer function itself, which is not the intention.
—Ruud 21:19, 16 February 2010 (UTC)

Ahhhh. I get it now. It's like a standard function execution call, except the first set of parentheses stands in for the name of the function. var myVar = myFunction(); => var myVar = (function() { do stuff })();
--Cogniac (talk) 22:27, 18 February 2010 (UTC)

Actually, the first set of parenthesis just stand for the parameters (none in this case) and there is no function name before the parameters because it's anonymous.
—Ruud 12:53, 19 February 2010 (UTC)

Well, based on that explanation, none of it makes any sense anymore. It would essentially be var myVar = myFunction(parameters go here)(what the hell are these parentheses for?); => var myVar = (supposedly there are no parameters, despite the fact that there's stuff in here)(still no idea what these parentheses are for); I thought that the first set of parentheses just grouped the outer anonymous function and the second set of parentheses was a call to execute that function.
--Cogniac (talk) 19:01, 26 February 2010 (UTC)