"authored_date","commit_date","author_name","author_email","message","case" "2013-10-04 23:08:13+02:00",2013-10-04 21:10:24,"Bartosz Dziewoński","matma.rex@gmail.com","Add .mw-editsection-like class, behavior same as .mw-editsection The styling is neat and can be used for other purposes on-wiki (examples include the {{Documentation}} template on the English Wikipedia and the index of biographies at the Polish Wikipedia at [[Wikipedia:Indeks biografii]]). Since .mw-editsection is often used by scripts enhancing the links (including VisualEditor and many gadgets) using it for other things might cause unexpected behavior. Existing uses can now be easily swapped for .mw-editsection-like. Change-Id: Ic390c3047e5e6fd3a351d0ec1ca94ebef9367f6d ","c1" "2013-07-18 02:47:55+02:00",2013-07-26 00:08:23,"Timo Tijhof","krinklemail@gmail.com","mediawiki.page.ready: Use wikipage.content instead of domready Restructure mediawiki.page.ready to add to the ""wikipage.content"" hook instead of using document-ready. Except for parts that aren't inside the wikipage content. Portlet links are outside content entirely and should run only once from document-ready still. Inputs with placeholders can be both inside and outside (inside with e.g. InputBox extension, outside in e.g. search bar of skin) so it needs to be in both. The one in document-ready needs to exclude ones in content to avoid applying the placeholder polyfill twice. This also opens up the doors for extensions and gadgets to reliably both fire and add to this hook: - Code can fire this hook when rendering a new DOM (such as LivePreview, VisualEditor, ..). - Code can add to this hook to enhance page content and have it properly re-run when there is a new DOM (e.g. gadgets like Navigation popups, Reference Tooltips, ..). Also added release notes for 2e97025. Bug: 30713 Bug: 33399 Bug: 51565 Change-Id: Icb0eda9edf2aeb3d612ff1d9bfea4859d33e1fbb ","c1" "2013-07-23 17:28:47-07:00",2013-07-24 00:31:27,"Roan Kattouw","roan.kattouw@gmail.com","Add a hook to Title::getEditNotices() so extensions can add them FlaggedRevs will have to use this to expose its edit notices to VisualEditor. Also add an $oldid parameter so edit notices can be generated based on the revision ID being edited. Change-Id: Ie44a01ebfa7002fa3a89f081e0f831442666ac03 ","c1" "2013-07-24 01:15:12+02:00",2013-07-23 23:38:42,"Timo Tijhof","krinklemail@gmail.com","mediawiki.notification: Make notification area sticky to window Whenever the user scrolls beyond the natural offset (possibly customised by the skin, e.g. in Vector it accounts for the tabs and search bar, in Monobook it is relative to the content area, etc.) we switch from absolute to fixed position. Changed the 1em top/right padding to be actual padding instead of part of the offset, as otherwise `window.scrollTop > offset.top` would trigger too late and thus cause it to ""jump"" back about 13px (1em) whenever we switch (the scroll logic depends on the floating-mode offset being 0). Now it seemlessly switches between the two area modes. Based on logic in VisualEditor for the sticky editor toolbar. Using a class instead of an ID for the area element as otherwise all selectors would require being like ""#area.area-floating"" to work from the skin. This should've been the case from the beginning (using IDs in CSS is almost always bad). Falls back to absolute position in IE6, where 'fixed' is not supported (and would use positon 'static' otherwise which would be a problem). Cleaned up useless 'null' value for $area variable. Bug: 50870 Change-Id: Icb7cd68f48443c1770e3585c8567fea2ac16dad8 ","c1" "2013-06-21 13:32:10+01:00",2013-07-15 10:26:02,"Ed Sanders","esanders@wikimedia.org","Allow postEdit hook to be triggered asynchronously This is required by VisualEditor as it doesn't do a page reload after a save. So we need it to keep listening even if the initial config and cookie data doesn't show an edit was just made. * Allow the message to be overriden, as VE uses its own. * Using jQuery instead of direct DOM interaction with `div` (and renamed to $div accordingly). * Moved click handler from postedit-close to postedit-container. Bug: 39632 Change-Id: I778b18bc051c51de355e122d8d4517b5a651ed4c ","c1" "2013-05-30 11:10:46-07:00",2013-05-31 21:25:49,"Ori Livneh","ori@wikimedia.org","Migrate Extension:PostEdit interface to core As requested by the VisualEditor team, this change migrates the post-edit confirmation notice from Extension:PostEdit to core. This entails porting the 'postedit-confirmation' en/qqq message from the extension's i18n file (the message key remains the same) to the appropriate message files and augmenting mediawiki.action.view.postEdit.js to not only signal post-edit state but also act on it by displaying the confirmation. Bug: 48276 Change-Id: I01cfc0630c3a505af82922844b5e70c1d61f3c1d ","c1" "2013-04-03 21:17:08+02:00",2013-04-03 21:46:11,"Timo Tijhof","ttijhof@wikimedia.org","Test: Assert that modules loaded correctly. Since mw.loader catches any uncaught exceptions that modules throw at run time, it is hard for QUnit and/or the browser (e.g. PhantomJS) to know about a failure because there is no assert failure and no uncaught exception (window.onerror). VisualEditor's init module, for example, has a problem (bug 45175) that sometimes causes an error, causing none of the tests to run, yet the QUnit run would finish successful with simply none of the VE tests included in the results. Bug: 44299 Change-Id: Ib6e2b8d1be3e38fd9f1b948407c62da550fce0b4 ","c1" "2013-03-21 19:45:17+01:00",2013-03-25 13:58:23,"Timo Tijhof","ttijhof@wikimedia.org","JSDuck: Cover more of external.js and implement @source Taken from VisualEditor repo (authored by myself under MIT). Hereby released under GPL as well. Change-Id: I4dc1a0e5c618e0a20ae6f308b4ecf266d041e22c ","c1" "2012-12-05 08:37:48+01:00",2012-12-16 22:13:04,"Timo Tijhof","ttijhof@wikimedia.org","ResourceLoader: Move safeFilemtime() to ResourceLoaderModule. This is a useful method not just for inside and sub classes of ResourceLoaderFileModule (i.e. it could've been useful in VisualEditor's ResourceLoaderModule class as well) Also moved up getTargets() to be in the right section (looking at the file as a whole). Change-Id: If696ffbdc5aa7f0a51603bcf9d52adab38b9c686 ","c1" "2012-11-30 12:18:43-08:00",2012-11-30 20:18:43,"Trevor Parscal","tparscal@wikimedia.org","Refactor edit notice rendering so that it's not baked into EditPage * Move edit notice rendering to Title class * Use new getEditNotices method in EditPage This opens the door for alternative editors (such as the VisualEditor) to use the same notice systems already in use. Change-Id: Ib0e40714f5433f4d75c54a3c3d60b1590fded7f1 ","c1" "2013-11-23 00:32:59-05:00",2013-11-30 18:29:54,"Mark A. Hershberger","mah@everybody.org","Restore Signupstart and Signupend messages for account creation This was removed during the redesign of the login process in I50f25583, but I found that 5-10% of non-wmf wiki sites used this message to display notices, previously. We should keep this around or at the very least provide advance notice for people. Bug: 56455 Change-Id: I79423c1a05f0359c902d1940c3ffcd5e509dcf97 ","c2" "2013-11-22 16:09:07+00:00",2013-11-22 16:09:07,"MarkAHershberger","mhershberger@wikimedia.org","Merge ""Fix login with temporary password with $wgSecureLogin = true""","c2" "2013-11-22 10:32:18+01:00",2013-11-22 14:46:55,"Alexandre Emsenhuber","ialex.wiki@gmail.com","Fix login with temporary password with $wgSecureLogin = true The problem is that FauxRequest sets the protocol to http by default, thus triggering the redirect when executing Special:UserLogin in the background to log the user in after having reset his password. DerivativeRequest is now used instead of FauxRequest so that the protocol is correctly forwarded, and the redirect will not be triggered. Bug: 57289 Change-Id: I252351ff7d446283c9d1ab5f79b5cdbce71b76e0 ","c2" "2013-11-08 21:00:00+01:00",2013-11-19 20:57:29,"Bartosz Dziewoński","matma.rex@gmail.com","Remove 'prefsnologin' message, don't use 'watchnologin' where inappropriate There is no reason why the default can't be used instead. No other special pages requiring login have special messages for the title, as far as I know. Left one use of 'watchnologin' in WatchAction alone, since it also uses another special message there. This message is also currently used by the MobileFrontend extension. Change-Id: I7878ed3692358cee1f5785b34ab48a0cc83c05bc ","c2" "2013-10-12 19:00:23+02:00",2013-11-19 11:03:49,"Bartosz Dziewoński","matma.rex@gmail.com","Consistently handle anonymous users on logged-in-only special pages Added new helper function SpecialPage#requireLogin() to check if the current user is logged in and, if not, format an error message linking to Special:Userlogin and throw UserNotLoggedIn exception, to be handled by OutputPage later. Reused old error messages. Not all use the new parameter and they're very inconsistent, but this is a matter for another patch. Used it on 7 special pages. I don't think there are any other ones which specifically require having an account, instead of just some rights usually associated with logged-in users. * SpecialChangeEmail * SpecialChangePassword: It allows anonymous users under specific circumstances, but is logged-in-only in general. * SpecialConfirmemail * SpecialEditWatchlist * SpecialPreferences * SpecialResetTokens: It was missing the check, added it. * SpecialWatchlist Change-Id: I43ceaddb370d09784021b3fc2d5d1ff6616fef1f ","c2" "2013-10-30 19:10:51+00:00",2013-10-30 19:10:51,"Tony Thomas","01tonythomas@gmail.com","Renamed ""Your name"" to ""Your username"" to match with the Media wiki login page Bug: 56235 Change-Id: Id7d303932b3ddf74308e2d9f3b54e08c6b1df5eb ","c2" "2013-10-16 18:24:12+02:00",2013-10-16 16:28:38,"Bartosz Dziewoński","matma.rex@gmail.com","Reindent UsercreateTemplate and UserloginTemplate A perceptive reviewer will note several issues with this code, including at least one outright bug. I intend to fix them in subsequent commit; I tried to avoid any non-whitespace changes here to make it at all possible to review this. This file has several lines longer than the phpcs limit of 100 characters, and several cases of the pattern phpcs complains about. I don't think it makes sense to enforce these rules here; the code would IMO become less readable. Change-Id: I95ab0f644fd5963878018f483f22e650867b5135 ","c2" "2013-10-16 10:29:39-04:00",2013-10-16 15:26:29,"Brad Jorsch","bjorsch@wikimedia.org","Include miscellaneous query parameters in $wgSecureLogin redirect The redirect from http to https should include any extra query parameters, such as the ones for ""campaigns"". But we still want to override returnto and returntoquery (in case they were changed in ::load(), e.g. lines 139–140), and we omit any 'title' parameter that may have been passed. Bug: 55761 Change-Id: Icc8b4132e8682d782b0c049631328b94745eb355 ","c2" "2013-10-11 13:42:10-06:00",2013-10-15 15:38:52,"Bryan Davis","bd808@wikimedia.org","Add configurable delay between purgeChangedPages batches UDP flooding is possible when purging large numbers of files. This change adds a command line switch to the purgeChangedPages.php maintenance script to insert an artificial delay between purge batches. The intent is to allow the network time to process the batch that was just sent before flooding with a second batch. `--sleep-per-batch` can be used in combination with `--batch-size` to manage network and to some extent query load. A suggested starting point would be to use `--sleep-per-batch=500` in concert with the default batch size of 100 to target a maximum rate of 200 packets/second. Bug: 55632 Change-Id: Ibfc54b1767f145098465404a2b23cd92852e41fd ","c2" "2013-10-08 13:11:54-07:00",2013-10-08 21:15:29,"Mark Holmquist","mtraceur@member.fsf.org","Quick refactor of the http logic in ForeignAPIRepo Automatic caching, will enable slightly smaller patches elsewhere. Resetting after failing at a rebase. Change-Id: I6849107a3af773687a31155b23a2d7b4d7a60645 ","c2" "2013-08-24 22:37:58+02:00",2013-10-06 19:00:26,"MatmaRex","matma.rex@gmail.com","Special:UserLogin UI improvements when user is logged in * Show a warning about being already logged in above login form * Show a button pointing to signup form with suitable explanation Also changed some internal template stuff (s/createAnother/loggedin/). Bug: 53306 Change-Id: I1672ee09330c231110c4db310a645d1382cc0b59 ","c2" "2013-10-05 10:14:24+02:00",2013-10-05 09:16:14,"Federico Leva","federicoleva@tiscali.it","Use a more standard ""Forgot your password?"" in userlogin-resetpassword-link Change-Id: I24ad148dd8b316ec1dc4de0b501eeeedb1940c0d ","c2" "2013-10-02 13:46:30-04:00",2013-10-02 20:01:42,"Brad Jorsch","bjorsch@wikimedia.org","Allow AbortLogin hook to override error messages The AbortLogin hook has a $msg argument that allows for specifying a MediaWiki message to display to the user. But this message is only used when the hook is aborted with LoginForm::ABORTED. There's no reason not to use this same parameter for the other possible failure constants. Note this is a slight change in behavior for the hook, as previously the $msg parameter would be coming in as ""login-abort-generic"" unless an earlier hook altered it, while now it will be null. Change-Id: Ib03a1aed9dfb566a027c31c015aa30619174a6c2 ","c2" "2013-09-27 13:39:50-07:00",2013-09-30 17:16:15,"csteipp","csteipp@wikimedia.org","Redirect to https for signup Redirect to https for most user, since they will be sending their password with their signup request. GeoIP prevention of the redirect is still respected. Bug: 53651 Change-Id: I12646fcd268c78fd446c6dbf2ba201eee3846444 ","c2" "2013-09-25 15:42:02-07:00",2013-09-25 22:42:02,"csteipp","csteipp@wikimedia.org","Vary on forceHTTPS cookie Varnish seems to be returning the cached version of pages for users after they have logged in over https, but access an http page. This seems to occure because only the forceHTTPS cookie is sent on the request, but varnish doesn't vary the cache based on that cookie. Bug: 54513 Change-Id: Ia97ed80622191669ee5ca37af809d307bbdb61ae ","c2" "2013-08-29 09:45:30-07:00",2013-09-03 22:04:47,"Brad Jorsch","bjorsch@wikimedia.org","SECURITY: Prevent tokens in jsonp mode Add checks to token-returning functions to prevent returning tokens in jsonp mode. This affects action=tokens, action=login, action=createaccount, and action=query&list=deletedrevs. Also, remove the ""gettoken"" parameter to action=block and action=unblock, which has been deprecated since 1.20. Bug: 49090 Change-Id: Ibeaa5c72d8084585092b15935a3f5709104bf7f7 ","c2" "2013-07-27 19:10:04+02:00",2013-09-01 09:48:15,"Nemo bis","federicoleva@tiscali.it","Make morenotlisted more grammar-friendly It's nice to be able to have different translations compared to moredotdotdot, but normally ""More not listed..."" is not worth the grammatical hassles and is not one-size-fits-all. Change-Id: Ica649d7630106143204c3495c544025439bb1921 ","c2" "2013-08-19 15:34:33+02:00",2013-09-01 09:39:59,"Nemo bis","federicoleva@tiscali.it","Use login-throttled properly everywhere Actually proper usage would probably be to split the messages. Followup to Id385be840f340476fbe7a818ff1d05154fe86d68; spotted by Shirayuki. https://translatewiki.net/wiki/Thread:Support/About_MediaWiki:Login-throttled/en Change-Id: I565971a90fc383327a51d717a80013cb7a3e9c9b ","c2" "2013-08-30 17:00:03-07:00",2013-08-31 00:00:03,"csteipp","csteipp@wikimedia.org","Also redirect if prefixed https cookie is preset After we switch to not using prefixes, still respect prefixed cookies for users who are currently logged in. Bug: 53538 Change-Id: I950e36e10420209fca28c41c438c363a3f332c14 ","c2" "2013-08-28 10:57:57-07:00",2013-08-28 18:57:57,"Chad Horohoe","chadh@wikimedia.org","Add help message to prefershttps The preference requires logging back in again to set the new cookies. Change-Id: I2602205eec752c927ac6df81545e69f5c9e70ee4 ","c2" "2013-08-20 13:29:23-07:00",2013-08-27 15:22:05,"Brian Wolff","bawolff+wn@gmail.com","Make thumb.php give http redirects if given a file redirect See bug 22390 for some of the background. Basically there's two reasons why we want this: * Hotlinkers to commons. We don't want to break their links when we move a file (Wikimedia blog is a prominent hotlinker) * Cached entires. On wikis using commons files, a file move doesn't trigger HTMLCacheUpdate jobs for the downstream wiki (it only triggers it on commons). This means that these pages will still use the old version of the html (with img tags that have the old url) until the next edit or purge action. But these urls won't work as soon as the file is moved. I'm pretty confident that redirects will work at this point in the thumb stack, as the redirects for long file names work fine (provided no thumb exists in swift with the wrong name). Change-Id: I40350121cf902f66fcbd3cf788335a988fa7ee33 ","c2" "2013-08-21 20:42:32-07:00",2013-08-24 18:04:23,"csteipp","csteipp@wikimedia.org","Setup cookies security based on user preference Use the user pref instead of the login form checkbox for setting up cookie security on login. The preferences menu is still broken (always shows checked, even if preference has been turned off), but this will log the user in (over https), and then redirect them back to http if they have selected to not use https. Likewise, if they have the default preference to use https, they get the forceHTTPS cookie and other cookies secure. Change-Id: I08f67b35f355ef193ae86cb9cca3799e247ead4e ","c2" "2013-08-23 12:34:06-07:00",2013-08-23 19:34:06,"Chad Horohoe","chadh@wikimedia.org","Only show prefershttps if IP can use HTTPS Change-Id: I7493a329d35fad3f17aac2df935f4f9306828884 ","c2" "2013-08-09 19:31:08+02:00",2013-08-23 00:48:33,"MatmaRex","matma.rex@gmail.com","Remove inconsistent font-family declarations Removed explicit uses of Helvetica Neue, Helvetica and Arial from mediawiki.ui (currently used in om account creation and login interface) and post-edit notifications. The browser is allowed to use its default font instead. Bug: 44394 Change-Id: I01eec72853b24d530d8733352a68d0a26967488f ","c2" "2013-08-23 00:49:01+01:00",2013-08-22 23:49:01,"Reedy","reedy@wikimedia.org","Fatal error: Call to a member function formatDuration() on a non-object in SpecialUserlogin.php on line 818 Bug: 53246 Change-Id: Ie2b23cefe569b31c2da67e16077d4557c6247bc9 ","c2" "2013-08-21 14:34:47+02:00",2013-08-21 12:34:47,"Platonides","platonides@gmail.com","Force a space between password label and reset link. userlogin-yourpassword and userlogin-resetpassword-link appeared concatenated if the css wasn't available: ""PasswordReset your password"" Change-Id: I59049a3f1f912c45da89b1441661c3b725e1459b ","c2" "2013-08-21 11:39:45+10:00",2013-08-21 03:43:46,"Tim Starling","tstarling@wikimedia.org","Core support for disabling HTTPS based on GeoIP * Introduce a hook allowing automatic redirects to HTTPS to be disabled on the basis of client IP address. * Make User::requiresHTTPS() return false if the client IP is blacklisted as such. * On login, make the ""stick HTTPS"" option default to false if the client IP address is blacklisted as such. * Do not redirect anonymous requests to HTTPS. * If $wgSecureLogin is enabled, link to the HTTPS login page *via* the HTTP redirect, so that there is no need to vary the cache of anonymous page view HTML on client IP address. Change-Id: Iaa9dd2108431b8c35e05db4bfe78a629018a003c ","c2" "2013-08-19 10:31:38-07:00",2013-08-20 00:13:56,"Chad Horohoe","chadh@wikimedia.org","Remove padlock icon from login link Change-Id: I021f7a92b84e73502328d8186dc7ca1e1946ca0d ","c2" "2013-02-01 12:25:53-05:00",2013-08-19 23:57:04,"Tyler Anthony Romeo","tylerromeo@gmail.com","Change secure login to use a user preference Removed the wpStickHTTPS checkbox from the login form, and instead just use the user's preferences along with whether they came from HTTPS or not to determine if they should stay in HTTPS. Bug: 29898 Bug: 52283 Change-Id: I69e9cb23b8d700e821b8a961c672958e4e19e4f8 ","c2" "2013-08-11 11:48:59+02:00",2013-08-18 08:01:31,"Nemo bis","federicoleva@tiscali.it","In login-throttled, specify how long you have to wait before logging in Throttle time will be enough to give an idea of the time to wait. The actual time seems to be the time since the first of the last n attempts in time t as per $wgPasswordAttemptThrottle, but it does not seem too bad if the user gets a new full pool of allowed attempts. Bug: 46965 Change-Id: Id385be840f340476fbe7a818ff1d05154fe86d68 ","c2" "2012-12-22 20:12:09+00:00",2013-08-13 14:45:37,"Alex Monk","krenair@gmail.com","Tweak login/account creation for logged in users * Don't show the ""Don't have an account? [Join ]"" box to logged-in users. * Use different message for ""Real name"" (disabled on WMF wikis) when creating another's account. Also document showCreateOrLoginLink() and set its visibility. Bug: 43172 Change-Id: I1b0bb6b78cbc5d37ef9f380a4bdf0f65d021a57f ","c2" "2013-08-07 12:21:22-04:00",2013-08-07 23:18:46,"Brad Jorsch","bjorsch@wikimedia.org","Add wfResetSessionID() The code for changing the session id cookie from Special:Userlogin is also needed in CentralAuth. So let's factor it out to avoid code duplication. Change-Id: I777f76ee8e2b953a1e972327bedc28e0ab1acf0d ","c2" "2013-08-06 16:04:15-04:00",2013-08-07 21:43:06,"Brad Jorsch","bjorsch@wikimedia.org","Improve WebResponse::setcookie Various bits of code are not using this because it doesn't support various use cases, e.g. session cookies, httpOnly, custom paths, etc. Refactor it to add all those options. Also add a hook so extensions can override the setting of the cookie. Change-Id: Ia0c424a48d9455a8574d91631cde0f00c9882288 ","c2" "2013-06-06 00:55:18-03:00",2013-08-07 19:05:07,"Brian Wolff","bawolff+wn@gmail.com","Have separate timeouts for upload by url ($wgCopyUpload[Async]Timeout) Add $wgCopyUploadTimeout and $wgCopyUploadAsyncTimeout to control the timeout for the http request used to fetch the file during upload by url. People reasonably may want to make this higher than $wgHTTPTimeout for the case where very large files are being downloaded. Also add the ability for callers of UploadFromUrl::fetchFile to override the timeout as they please (and set any other HTTP opts). This patch was inspired by conversation with dan-nl about gwtoolset. Change-Id: Ia85a97434c14adcdaafc0802cbe0530bfa57a435 ","c2" "2013-08-05 20:15:49+02:00",2013-08-05 18:44:53,"addshore","addshorewiki@gmail.com","Allow different users to login in Api tests Change-Id: I6f79416e4580ed8bf57836b78aa7027ea8f0d280 ","c2" "2013-07-24 01:15:12+02:00",2013-07-23 23:38:42,"Timo Tijhof","krinklemail@gmail.com","mediawiki.notification: Make notification area sticky to window Whenever the user scrolls beyond the natural offset (possibly customised by the skin, e.g. in Vector it accounts for the tabs and search bar, in Monobook it is relative to the content area, etc.) we switch from absolute to fixed position. Changed the 1em top/right padding to be actual padding instead of part of the offset, as otherwise `window.scrollTop > offset.top` would trigger too late and thus cause it to ""jump"" back about 13px (1em) whenever we switch (the scroll logic depends on the floating-mode offset being 0). Now it seemlessly switches between the two area modes. Based on logic in VisualEditor for the sticky editor toolbar. Using a class instead of an ID for the area element as otherwise all selectors would require being like ""#area.area-floating"" to work from the skin. This should've been the case from the beginning (using IDs in CSS is almost always bad). Falls back to absolute position in IE6, where 'fixed' is not supported (and would use positon 'static' otherwise which would be a problem). Cleaned up useless 'null' value for $area variable. Bug: 50870 Change-Id: Icb7cd68f48443c1770e3585c8567fea2ac16dad8 ","c2" "2013-07-06 13:29:13+00:00",2013-07-06 13:29:13,"TheDJ","hartman.wiki@gmail.com","Merge ""SpecialUserlogin: fix typo in comment""","c2" "2013-06-30 22:46:45+02:00",2013-07-01 23:35:02,"MatmaRex","matma.rex@gmail.com","SpecialUserlogin: fix typo in comment Change-Id: Ia67e2b0b87ca09aaa1ad285867ccd3f4a95a6026","c2" "2013-04-23 11:57:31+01:00",2013-06-30 21:30:27,"Reedy","reedy@wikimedia.org","Lossless PNG compression... Change-Id: I392f050e8ba1b5b1d28bc958a124cb237d8ea4b6 ","c2" "2013-06-20 22:13:18-04:00",2013-06-27 19:30:31,"Matthew Flaschen","mflaschen@wikimedia.org","Preserve returnto when upload requires logging in Changes link text to loginreqlink message since OutputPage->showPermissionsErrorPage passes that in. Change-Id: Iebde4398cdb74eb2fcc441601f074c93a7ad6073 ","c2" "2013-06-19 22:25:40-07:00",2013-06-20 05:25:40,"S Page","spage@wikimedia.org","Restore messages of old login and signup forms The change 44840d15929d8ecfc1d7c31d6f7e86d873ac15a2 ""Only new vertical format login and signup forms"" removed some messages no longer used in core, but 'userlogin' is used by extensions including MobileFrontend This restores the messages but marks them as unused in core and deprecated. Change-Id: I82c4fc37481a4a0dea1e839238188f6555e3c60d ","c2" "2013-06-04 22:20:00-07:00",2013-06-18 06:29:50,"S Page","spage@wikimedia.org","Only new vertical format login and signup forms * The ""VForm"" templates replace existing templates. * Remove useNew switch logic and $wgUseVForm{UserLogin,CreateAccount}. * The CSS and JS files for forms lose the .vform qualifier, except for the CSS for styling vform elements. * Merge tiny mediawiki.special.userLogin.signup.js into createAccount.js. * Remove replaced and obsolete messages (see https://www.mediawiki.org/wiki/Account_creation_user_experience/Strings for details), and remove mention of ""new"" forms and useNew from MessagesQqq.php. Bug: 46333 Change-Id: I50f25583c3aa9a4a263fb40f50256f92c18ddb4d ","c2" "2013-05-12 15:26:49+00:00",2013-06-11 01:02:13,"Niklas Laxström","niklas.laxstrom@gmail.com","mediawiki.api: Implement login method Change-Id: I1113a076ff66e20ece1db9380969e7a7b5a68f1a ","c2" "2013-03-18 17:46:39-04:00",2013-06-04 22:27:46,"Tyler Anthony Romeo","tylerromeo@gmail.com","Added SSL verification to PHPHttpRequest. PHP's stream context options support SSL server verification as well a CN matching and provision of CA info. Added options to the stream context so that the $sslVerifyHost, $sslVerifyCert, and $caInfo parameters now work in non-CURL environments. Change-Id: Iab2bda1ebcf20b625b019c91ae6352b5405dcc01 ","c2" "2013-05-29 15:06:39-07:00",2013-05-29 22:22:11,"S Page","spage@wikimedia.org","Darker labels in new login and create acct forms Bug: 47777 Change-Id: I01dd960d673a37d519ae8805db1fbbcb5a4306c9 ","c2" "2013-05-13 17:33:13-04:00",2013-05-13 21:33:13,"Matthew Flaschen","mflaschen@wikimedia.org","Fix Qqq link for userlogin-resetpassword-link * ResetPassword redirects to ChangePassword, which doesn't work logged out * PasswordReset is the actual ""forgot my password"". Change-Id: I4b9a7c3fe80feb8d2a8e4fe3be1238d2cc55d348 ","c2" "2013-05-09 16:55:07-07:00",2013-05-11 06:57:15,"S Page","spage@wikimedia.org","Message changes for new login form Shorter ""Reset your password"" (new key userlogin-resetpassword-link). Shorter ""Use secure connection"" (existing key userlogin-signwithsecure). Better explanations. Change-Id: Ia8e4219b200c25a61cbbade36841bb2c45cc9704 ","c2" "2013-05-02 22:47:40+00:00",2013-05-02 22:47:40,"Ori.livneh","ori@wikimedia.org","Merge ""Message tweaks to new login and create acct forms""","c2" "2013-04-26 22:00:55-07:00",2013-05-01 03:06:58,"S Page","spage@wikimedia.org","Message tweaks to new login and create acct forms * ""Keep me logged in"" (bug 47694) * ""[Create my account]"" submit button (bug 47700) * ""Why you are creating another account"" placeholder (bug 31888) Bug: 47694 Bug: 47700 Bug: 31888 Change-Id: I7cfa4bb36368277a934144c1724ec437c426eacf ","c2" "2013-04-05 21:57:03-04:00",2013-04-23 22:56:02,"Matthew Flaschen","mflaschen@wikimedia.org","Create account form with vertical form appearance Similar to the login form (change 55847), this presents a compact vertically-stacked form, if a global variable is set or if you add ?useNew=1 to the query string. The redesigned create account form also: * Removes the remember me checkbox (see bugzilla 47267) * Displays some wiki statistics in a benefits column. * Repositions the FancyCaptcha image if present using JavaScript (see bugzilla 47372). * Sets the template skin as in change 59577. Bug: 44628 Bug: 47267 Change-Id: I9b03d519af43de147bff0ac509a1154f67cd3a0a ","c2" "2013-04-16 20:51:18-07:00",2013-04-17 06:13:56,"Ori Livneh","ori@wikimedia.org","Set 'skin' template parameter rather than override parent method BaseTemplate's getSkin() method is perfectly adequate if you simply set a skin value where it expects it. Doing so obviates the need to reimplement getSkin() in UserloginTemplateVForm and UsercreateTemplateVForm. Change-Id: Icd22de2218fc96cb67c11d0c1763b607743fe3b6 ","c2" "2013-03-04 19:13:39-08:00",2013-04-11 22:26:45,"S Page","spage@wikimedia.org","Revised design of Special:Userlogin If a global variable is set or if you add ?useNew=1 to the query string, Special:Userlogin loads a different login template (UserloginVForm.php) with the new Vertical Form appearance and different messaging. Otherwise the current unchanged template renders so that wikis can cut over to the new look when ready (with messages and links). Once they do so, the variable and flag will be retired. The new template applies mw-ui-vform and mw-ui-button styles defined in a new 'mediawiki.ui' CSS module in core to create a compact vertical form. The mw-ui styles specify a Helvetica font stack (that we tested in the Account creation experiment) in the form area, but NOT if the user is using some other skin than Vector. The CSS code is developed using Sass. The patch includes the Sass scss files, along with a Makefile that uses their Compass build configuration (config.rb). The redesigned Special:Userlogin also: * Displays a ""secure login"" link if HTTPS is available. * Loads additional CSS for its form features (e.g. more attractive errorbox, ""Join wiki"" messaging). * Defines new ""userlogin-xx"" messages; many are the same as existing messages but without ':' on the end. * Uses a distinct title for Login instead of generic ""Log in / Create account"". * Removes the [mailmypassword] code branch from its login template as it is never executed. Bug: 44628 Change-Id: I489042c50aa060c90ca18b05097dbe25c4ae6395 ","c2" "2013-02-18 20:43:03+01:00",2013-04-10 08:04:16,"jeroendedauw","jeroendedauw@gmail.com","Remove dependency on ORMTable from ORMRow IORMRow implementing objects take a IORMTable object in their constructor. The later is a hard to construct service object while the former ideally should just be a simple wrapper around a database row. This means IORMRow objects are tightly coupled with IORMTable objects, which makes them inflexible and makes various things such as testing logic contained in them needlessly difficult. This commit gets rid of this nonsense by allowing for construction of ORMRow objects without providing an ORMTable. All methods dependent on the table field have been deprecated. Most of these methods have a new alternative in ORMTable. For instance, saving an ORMRow can now be done by passing an instance of ORMRow to the updateRow method of an ORMTable instance, rather then calling save on the ORMRow instance. Backwards compatibility has been retained except for the fields passed in the constructor no longer undergoing magical unserialization if it looks like this is needed. I do not expect this will affect any existing code though. Change-Id: I86368821fc2cd0729df5342b8572eb470c0f77a0 ","c2" "2013-02-22 10:36:55+01:00",2013-04-09 21:49:27,"Pau Giner","pau.giner@gmail.com","Add SVG version of user icon in Vector personal portlet An SVG version of the user icon is provided only for browsers supporting SVG. To ensure browser compatibility, the SVG version is provided in a two-layer background where the first layer is a transparent gradient. The fact that browsers supporting CSS gradients are a strict subset of those supporting SVG guarantees an appropriate fallback. Embedding is used to avoid extra http requests. Bug: 35341 Change-Id: I914da0649459744ccca9e1a78e9f48fe66e1a77f ","c2" "2013-03-20 15:48:28-04:00",2013-04-04 14:09:34,"Chad Horohoe","chadh@wikimedia.org","Remove ExternalUser authentication code This was an experimental authentication system intoduced a couple of years ago with a pretty narrow use-case. It's been pretty much ignored since introduction, and makes login more complicated than it needs to be. I didn't drop the external_user table on the off-chance someone out there actually has data in it, but they should use AuthPlugin for their external authentication needs. Change-Id: I794338dbb75961ee033d41fa44bb7aa22e54f447 ","c2" "2013-03-28 12:54:11+01:00",2013-04-01 15:43:28,"Siebrand Mazeland","s.mazeland@xs4all.nl","Reduced indentation levels, broke long lines. Reversed login a two cases to get there. Also updated PHPDoc, removed an unneeded comment and removed superfluous newlines. Change-Id: Ica5f7d24171e2eaeccc0743f8800e18cf2de8006 ","c2" "2013-03-09 06:57:07-04:00",2013-03-27 11:41:20,"Brian Wolff","bawolff+wn@gmail.com","Set lang in api createaccount regardless of $wgLoginLanguageSelector $wgLoginLanguageSelector is related to how the interface of special:userlogin works. It doesn't make sense to listen to it in the api module Also throw error if invalid lang code is specified (for sanity) Change-Id: Ibf72fd5a318cadc450b3b579757ee8145864a27a ","c2" "2013-03-19 19:52:13+00:00",2013-03-19 20:10:19,"Matmarex","matma.rex@gmail.com","Revert ""Change login/createaccount forms to new appearance"" The code did not go through a proper review process, and - quite simply - it is unacceptable by core standards (or by any standards, to be honest). * It ""[u]ses JavaScript to munge the create account CAPTCHA"", to quote the commit message * It is littered with TODOs and FIXMEs, as well as messages from one coder to the other and commented-out code * It modifies some HTTPS-related logic for no obvious reason (it's not documented or even mentioned *at all* in a otherwise front-end changeset) * It happily disregards code conventions (trailing spaces, #-comments, CSS formatting) * It includes different CSS font-family rules that the entire rest of software uses for display, creating design inconsistency * It hardcodes links in the format ""/wiki/XXX"" * It hardcodes English-language link hrefs This reverts commit 92bb00d35688e72ebeea75ed55a6db981cfb71e5 Conflicts: languages/messages/MessagesEn.php Change-Id: I00d72fe157e697d5cf926e75bcea5db0bee153e5 ","c2" "2013-03-04 19:13:39-08:00",2013-03-19 04:12:03,"S Page","spage@wikimedia.org","Change login/createaccount forms to new appearance If a global variable is set or if you add ?useAgora=1 to the query string, Special:Userlogin loads a different login or create account template (Userlogin-/UsercreateAgora.php) with an Agora look and different messaging. Otherwise the current form is unchanged so that wikis can cut over to the new look when desired. These new templates apply mw-ui-formlist and mw-ui-button styles defined in a new 'mediawiki.ui' CSS module in core (copied from Extension:Agora). In useAgora mode, Special:Userlogin also: * Adds new modules with some additional CSS for new form features (""Join wiki"", benefits of creating an account). * Defines new ""userlogin/usercreate-xx"" messages, many are the same as existing messages but without ':' on the end. * Uses a distinct title for each mode instead of generic ""Log in / Create account"". * Uses JavaScript to munge the create account CAPTCHA. * Outputs checkboxes using UserloginTemplateAgora::labelledCheck() * Displays a benefits column of wiki edits/users/contributor numbers. TODO: - Restyle/reposition language selector - Munge CAPTCHA in PHP not JavaScript, i18n of new CAPTCHA messages. - Identify the subset of Agora appropriate for non-Vector skins and create mediawiki.ui.default.css from that. Patch set 18: Agora styles now in core. Bug: 44628 Change-Id: I859edab4fc4fa9fe35fdef15fc429ae19a95305d ","c2" "2013-03-18 18:46:26+00:00",2013-03-18 18:47:05,"Yuvipanda","yuvipanda@gmail.com","Merge ""(Bug 45775) Adjusted the margin of ""userloginForm""""","c2" "2013-03-13 23:38:31+05:30",2013-03-18 18:36:19,"rahul21","rahul14m93@gmail.com","(Bug 45775) Adjusted the margin of ""userloginForm"" Change-Id: Ibede75a3f4e998d1972cacf1f5840882d39550ee ","c2" "2013-03-15 15:15:17-07:00",2013-03-15 22:15:17,"Ryan Lane","rlane@wikimedia.org","Add id for domain list on user create form The user login form already has this id for the domain list, so I'm adding it for the create form as well. Change-Id: I1eec31c461a5c76565acf1e0bbfa07f367591678 ","c2" "2013-02-27 17:58:52-08:00",2013-02-28 02:03:44,"Tim Starling","tstarling@wikimedia.org","Preserve caller expectations for behaviour of sslVerifyHost (bug 42441) The previous patch unnecessarily broke backwards compatibility in the Http::request() API, following cURL's broken conventions for sslVerifyHost instead of the boolean interpretation expected by all existing callers. This change reverts that one, and fixes the bug in another way. See Ia6535f10. Also don't bother wrapping the $this->sslVerifyHost access with isset() since it's always set. Change-Id: Ia4e1689249b6ac515b859ea2eca1dcff3e63098c ","c2" "2013-02-13 06:22:54+00:00",2013-02-13 06:22:54,"Krinkle","ttijhof@wikimedia.org","Merge ""Revert ""phpcs: Convert var to public in SpecialUserlogin.php""""","c2" "2013-02-13 06:19:24+00:00",2013-02-13 06:19:24,"Krinkle","ttijhof@wikimedia.org","Revert ""phpcs: Convert var to public in SpecialUserlogin.php"" This reverts commit 343382e4b783d528d7b1a3153681463c4c6a4597 Change-Id: I5609ab996a178d58a532d6a0bfc3d952d0629c1c ","c2" "2013-02-11 19:23:37-08:00",2013-02-12 03:23:37,"S Page","spage@wikimedia.org","Avoid Jenkins' CodeSniffer warnings for Userlogin Change property declarations from ""var"" to ""public"". This eliminates the 46 | ERROR | The var keyword must not be used to declare a property warnings from Jenkins CI, e.g. https://integration.mediawiki.org/ci/job/mediawiki-core-phpcs-HEAD/1565/console http://php.net/manual/en/language.oop5.properties.php says ""If you declare a property using var instead of one of public, protected, or private, then PHP 5 will treat the property as if it had been declared as public."" , so this should be a no-op. Change-Id: I754ccea018f95421bfe3f7b04e3ab3a6d9b407e3 ","c2" "2013-02-08 14:07:40+01:00",2013-02-08 13:07:40,"Alexandre Emsenhuber","ialex.wiki@gmail.com","Correct check whether the e-mail field was filled in Special:Userlogin/signup Use a strict comparison with '' instead of empty(), otherwise this allows user to give ""0"" as an e-mail address. Also use strval() if in any case null or something like that would be passed. Change-Id: Ide7d35c52a04d05b43ae9fd37f7586bb4a67d4ed ","c2" "2012-12-16 19:18:24+08:00",2013-01-12 08:19:32,"Liangent","liangent@gmail.com","(bug 22457) More natural flow for the ""By e-mail"" feature This feature is on Special:Userlogin/signup to allow a random new password to be sent to expected account owner on assisted signup. It uses JavaScript to hide the password & retype password fields when a logged-in user creates an account (for someone else) and checks the by e-mail feature. Change-Id: I7bf57eef64fea19a8237f997019e0b2bfdf401b3 ","c2" "2012-10-08 00:21:08-04:00",2012-12-14 01:45:16,"Tyler Anthony Romeo","tylerromeo@gmail.com","(bug 40679) Set $wgSecureLogin to false for $wgServers with schemes. When $wgServer has a scheme, force $wgSecureLogin to false in order to stop infinite redirects when trying to go to the login page. Change-Id: I5792eb1a54c7b6279aad0531cedf9f7b4bf94e6e ","c2" "2012-12-07 14:54:20-05:00",2012-12-12 18:20:53,"Tyler Anthony Romeo","tylerromeo@gmail.com","(bug 42832) Fixed cookie security when not wpStickHTTPS. When a user goes to a secure login page, but does not want to stick to HTTPS, reset the session so that all session cookies are not secure otherwise the session won't be setup on HTTP. Change-Id: I54ba02b723442f6d8b585f0f86a572b56be06596 ","c2" "2012-11-29 14:02:18-08:00",2012-11-29 22:18:31,"csteipp","csteipp@wikimedia.org","(bug 40995) Refresh SessionId on login SpecialUserlogin updated to refresh the user's session_id on each successful login. Change-Id: I1bd76f2c199b515f570e18669ca2138668bf847e ","c2" "2012-10-24 01:18:08+02:00",2012-11-20 13:45:11,"Marius Hoch","hoo@online.de","(bug 36053) Login returnto doesn't work if title isn't in the URI Returnto after login didn't work if title wasn't given as URI parameter. I'm using $this->getTitle() to find it out, in case the user got read rights (per code comment above my change). Change-Id: I14d92581ce790355404d3c184fa6542a24f7a130 ","c2" "2012-11-19 17:33:31+01:00",2012-11-19 16:33:48,"Timo Tijhof","ttijhof@wikimedia.org","Cleanup: Fix yoda and indentation in SpecialUserlogin.php Change-Id: I0bde21a8da679350559779132dbd7b1ba85116d1 ","c2" "2012-11-13 23:32:27+00:00",2012-11-13 23:32:27,"Anomie","bjorsch@wikimedia.org","Merge ""Separated validation login in SpecialBlock.""","c2" "2012-11-03 00:56:24-04:00",2012-11-03 20:51:07,"Tyler Anthony Romeo","tylerromeo@gmail.com","Separated validation login in SpecialBlock. Separated SpecialBlock::validateTargetField so that it can be used without needing an HTMLForm. Now there is a function SpecialBlock::validateTarget that does the actual validation. Change-Id: I70d854b95e864b249c8a1862bda3b6cbef4f682d ","c2" "2012-10-21 22:43:45+02:00",2012-10-21 20:43:45,"mrbluesky","mrbluesky@wikipedia.be","Correcting system message linksearch-text The introduction on Special:LinkSearch is not correct: when no protocol is specified, http is used. To search for links with another protocol, the protocol has to specified. Change-Id: Iaaebc3770c3463e59784df0fd601e08c835a2e23 ","c2" "2012-09-27 20:24:19+02:00",2012-10-13 16:03:08,"Federico Leva","federicoleva@tiscali.it","SI standards for time units * Use ""min"" rather than ""m"". * Add normal spaces to avoid hassles, no wrapping here anyway. Change-Id: I07f7aff41a831c88b82d6ddc53914372d6aec023 ","c2" "2012-10-09 17:37:25+00:00",2012-10-09 17:37:25,"CSteipp","csteipp@wikimedia.org","Merge ""(bug 40789) Fixed $wgSecureLogin after-login redirect.""","c2" "2012-10-09 09:45:03+11:00",2012-10-08 23:20:45,"Tim Starling","tstarling@wikimedia.org","(bug 16020) Fix race condition in User::addToDatabase() Fix the DB error which comes from User::addToDatabase() if it is called when the user already exists. This is the most common DB error we log at WMF in normal operation, perhaps because of double clicks on the ""create account"" button, or perhaps due to CentralAuth autocreation when multiple pages on another wiki are opened in the browser simultaneously, as the bug reporter suggests. See the doc comment for the interface rationale. Patched Special:Userlogin to be aware of the new return value. Most extension callers will continue to work, I will patch a couple that need it in subsequent commits. Change-Id: I1f6ef5e6319bfe692fb82a3fa50dc66c9fde8f15 ","c2" "2012-10-07 10:17:31-04:00",2012-10-07 14:17:31,"Tyler Anthony Romeo","tylerromeo@gmail.com","(bug 40789) Fixed $wgSecureLogin after-login redirect. Check for $wgSecureLogin accidentally redirected users to HTTPS when $wgSecureLogin was off. This fixes the conditional statement so that when secure login is off original functionality is preserved. Change-Id: Ida8a2de849e2ad208129b272936ebc5806a16d71 ","c2" "2012-10-06 20:08:20+00:00",2012-10-06 20:08:20,"Siebrand","siebrand@wikimedia.org","Merge ""(bug 23222) The ""login again"" link on Special:Userlogout now has returnto parameter""","c2" "2012-10-06 14:50:28+02:00",2012-10-06 13:05:31,"Alexandre Emsenhuber","ialex.wiki@gmail.com","(bug 23222) The ""login again"" link on Special:Userlogout now has returnto parameter It is much more user-firendly for user that logout and then click the ""login again"" to have the ""Return to"" links pointing to the page they were before logging out. Based on patch by Ilmari Karonen. Change-Id: Ia63d7743b9a02ee81eb76cdd34da375a66589059 ","c2" "2012-09-27 19:01:49+02:00",2012-10-04 19:39:38,"MatmaRex","matma.rex@gmail.com","CologneBlue rewrite: don't display login/out links in sidebar They do not belong to ""My pages"". Instead, display them properly in syslinks, respecting $wgUseCombinedLoginLink and creating them via usual means. Change-Id: I8e2cc25e41e46a471b98e0d18336c753b8645d0e ","c2" "2012-09-29 12:36:33+02:00",2012-10-03 23:15:38,"umherirrender","umherirrender_de.wp@web.de","(bug 32951) Do not register absolute internal externals Setting $wgRegisterInternalExternals = false for proto server should not store the http/https links in externallinks table Also fix detection of own links for links with query or anchor or nothing new also detected: //localhost //localhost?query //localhost#anchor already detected: //localhost/path Change-Id: Idd03d309cc3b71728a8cbea460efa12b10348d64","c2" "2012-09-27 14:34:11-04:00",2012-09-27 18:34:11,"Tyler Anthony Romeo","tylerromeo@gmail.com","(bug 40541) Fixed $wgSecureLogin functionality. * Added parameter to login link so that wpStickHTTPS is set to true by default when the user is coming from HTTPS. * Added redirect in Special:Userlogin so that when $wgSecureLogin is enabled it automatically redirects to HTTPS. * Adjusted User::setCookies() to add a parameter for forcing secure/insecure cookies, and then added the appropriate argument to Special:Userlogin so that cookies are set appropriately. Change-Id: I17ac68014840daa47bfd4768e978e9ff2edb00db ","c2" "2012-09-27 00:25:52+00:00",2012-09-27 00:25:52,"Demon","chadh@wikimedia.org","Merge ""(bug 33471) compare detectProtocol to 'https'""","c2" "2012-09-26 17:20:15-07:00",2012-09-27 00:20:15,"csteipp","csteipp@wikimedia.org","(bug 33471) compare detectProtocol to 'https' Extra ':' was added to the comparison string in gerrit change I6adc7e3e Change-Id: I3ff7274f6aa006b5cb9dcc3d2c44721f25a0fc8f ","c2" "2012-09-17 11:10:30-07:00",2012-09-21 22:47:59,"csteipp","csteipp@wikimedia.org","(bug 29898) Set cookie to force HTTPS from HTTP Sets a cookie on user login (removed on logout) if wpStickHTTPS was checked, which causes the browser to get a redirect if they visit the HTTP version of the site. Change-Id: I60f44a1062a93d15198edae6674bb3310a148b2d ","c2" "2012-09-12 17:43:48+00:00",2012-09-12 17:43:48,"Reedy","reedy@wikimedia.org","Merge ""Fix fatal error in rcprop=loginfo""","c2" "2012-09-12 03:36:12+00:00",2012-09-12 03:36:12,"Reedy","reedy@wikimedia.org","Merge ""Link to mediawiki.org using https from doxygen first page, not http""","c2" "2012-09-11 21:43:29+02:00",2012-09-11 19:43:29,"Alexandre Emsenhuber","ialex.wiki@gmail.com","Link to mediawiki.org using https from doxygen first page, not http Change-Id: I13fe244e6122930731f144f97f27126339065481 ","c2" "2012-09-10 13:15:59-07:00",2012-09-10 23:44:43,"Catrope","roan.kattouw@gmail.com","Fix fatal error in rcprop=loginfo There was a recentchanges row on enwiki whose rc_params looked like array('4::tags'=>array('db-g11')), and the tag name wasn't set recursively so the inner array didn't get a tag name. This still generates invalid XML of course, because <4::tags> isn't a valid tag, but at least it doesn't fatal any more. RAWR XML GRUMBLE Change-Id: Ibb775df4bd010bdce5632914f789230d8626c9e7 ","c2" "2012-08-23 20:34:35+00:00",2012-08-23 20:34:35,"Demon","chadh@wikimedia.org","Merge ""Fix separated login link so that create account and login are always next to each other.""","c2" "2012-07-29 16:06:37+02:00",2012-08-19 09:48:11,"Derk-Jan Hartman","hartman@videolan.org","Add lang and hreflang attributes to the language links of the login page. - Adding these attribues should make them easier to interpret for VoiceOver and other assitive technologies. - This assumes that people will enter the name of the language in the target language to MediaWiki:loginlanguagelinks, which is a convention but not a requirement of course. However I think making the bet that people actually do that is safe enough. - Switch the name of the old attr variable to query, which better reflects what it is supposed to be used for. Change-Id: I0cdae9f1e539b9b9c2b99ea1db1ba62bbbb0bdc5 ","c2" "2012-08-15 16:44:41-04:00",2012-08-16 14:48:07,"Tyler Anthony Romeo","tylerromeo@gmail.com","(bug 32774) Added config options and flags for SSL and compression in DB. Added configuration options ($wgDBssl, $wgDBcompress) and related connection flags (DBO_SSL, DBO_COMPRESS) to allow SSL/TLS and compression on database connections. The flags are only observed if the functionality is supported for that type of database (e.g., SQLite will ignore both flags as neither are supported). Currently, only MySQL and PgSQL have support for at least one of these flags in their PHP extensions. MySQL supports both flags and PgSQL supports the SSL flag only. Change-Id: I7b4d3ba82ccab0eed4a19e3b4e7bc0b4eb881262 Signed-off-by: Tyler Anthony Romeo ","c2" "2012-08-15 13:56:23-07:00",2012-08-15 20:58:41,"Daniel Friesen","pub-github@nadir-seen-fire.com","Fix separated login link so that create account and login are always next to each other. Change-Id: Iea0b325f66987a3a2de2c0935998e75f834d5786 ","c2" "2012-08-12 00:28:58+01:00",2012-08-11 23:28:58,"Reedy","reedy@wikimedia.org","Update message specialpages-group-login to match other similar messages Swap signup for create account Change-Id: I3b90729a345946b48c1fc30e1d3bdd4a192f5283 ","c2" "2012-06-22 12:37:47+02:00",2012-06-26 14:03:42,"Antoine Musso","hashar@free.fr","(bug 37627) generic exception for not logged in users We have various place in MediaWiki core and in extensions which are showing anonymous user a very standard error page about them not being logged in. Each developer ends up writing its own because we do not provide a generic error, that is what this patch does. This UserNotLoggedIn exception, when called, will show the usual ErrorPage with a default title and default reason text. That makes it as easy to use as doing: if( $user->isAnon() ) { throw new UserNotLoggedIn(); } One can override the default reason by passing a message key as the first parameter: if( $user->isAnon() ) { throw new UserNotLoggedIn( 'nologin-reason-text' ); } In that case, the page title will still be the default 'Not Logged In.' Change-Id: Id81272995627bf0f5bbef785230a8e6e4e8582ca ","c2" "2012-06-22 21:39:47+00:00",2012-06-22 21:39:47,"Catrope","roan.kattouw@gmail.com","Merge ""API: Reset token cache on login, so API tests work""","c2" "2012-06-22 22:37:26+02:00",2012-06-22 21:34:59,"daniel","daniel.kinzler@wikimedia.de","API: Reset token cache on login, so API tests work Previously, logging in several times during a phpunit run would change the session token, but keep the edit token, leasing to ""bad token"" failures for all but the first login. Change-Id: Iad49c990c5661d55cd907b8441addb74eb0ef694 ","c2" "2012-06-07 22:37:17+00:00",2012-06-07 22:37:18,"Aaron Schulz","aschulz@wikimedia.org","Merge ""Userlogin: Do not add a language link if it's the currently used language""","c2" "2012-06-07 20:59:57+00:00",2012-06-07 20:59:57,"Aaron Schulz","aschulz@wikimedia.org","Merge ""Change order of login/create account""","c2" "2012-06-07 17:25:38+02:00",2012-06-07 15:29:41,"robin","robinp.1273@gmail.com","Userlogin: Do not add a language link if it's the currently used language (Just display the language name without a link) Change-Id: I604d2905d73faf5b2242fdbf943262ae22e58a2c ","c2" "2012-06-06 19:48:27+02:00",2012-06-06 17:49:36,"umherirrender","umherirrender_de.wp@web.de","Change order of login/create account With this the position of the login link in the right corner is not changed with $wgUseCombindedLoginLink = false; Gerrit has also first ""register"" and than ""log in"" in the corner. Change-Id: I8d1000cf53ab792b3f69438004e5ae181acba645 ","c2" "2012-06-06 17:03:27+00:00",2012-06-06 17:03:27,"Catrope","roan.kattouw@gmail.com","Merge ""Increased uselessly low $wgBlockCIDRLimit default for IPv6.""","c2" "2012-06-05 17:01:43-07:00",2012-06-06 00:01:43,"Aaron","aschulz@wikimedia.org","Increased uselessly low $wgBlockCIDRLimit default for IPv6. Change-Id: I5abc83981912f304c4034a32063ba09bcf6aa1b1 ","c2" "2012-04-13 22:37:33+02:00",2012-04-19 16:25:45,"Platonides","platonides@gmail.com","(bug 35961) Hash comparison should always be strict. If your salted password end up being completely numeric when represented in hexadecimal (less than 1 password per 10 millions), it is also possible to login by providing another password that only matches the first 9 bytes (instead of the full 16 ones) if it turns out to also be completely numeric with your assigned salt (which is completely unknown). The odds of finding an equivalent password with such characteristics, over a double md5 with an unknown salt, are really low. Even if the attacker broke into the servers and robbed the salts, making use of this property would require a preimage attack of a partial md5 (2^18) with the output of another md5 hash, for which a full preimage would still be needed. Breaking the hashes using conventional attacks would be easier, so this is not a critical update. Change-Id: I8d1153fb91ca6507bd1df91e9953561f74f12ef6 ","c2" "2012-04-07 18:52:02+02:00",2012-04-07 16:52:02,"lupo","lupo.bugzilla@gmail.com","(bug 35658) make mw.Uri handle uris w/o protocol or host Includes testcase. mw.Uri already supplied the protocol if it was missing and document.location was set. Newly it also supplies the host (and port) from document.location if that is set. That enables handling of root-relative URls like ""/some/path"". Changeset 2/3: rename test file from mediaWiki.Uri.test.js to mediawiki.Uri.test.js. Changeset 4: fix jasmine tests. Test for 'http:/foo.com' is now expected to succeed, not throw an exception. The second test for 'foo.com/bar/baz' in strict mode is correct; that's parsed in strict mode as a truly relative path. Change-Id: Ibc4386ba40cffea9d30417ec2720114f6819ae1c ","c2" "2012-04-05 19:00:04+00:00",2012-04-05 19:00:04,"Aaron Schulz","aschulz@wikimedia.org","Merge ""Making https svnroot point to https viewvc, not https viewvc to https viewvc, as that wouldn't replace anything""","c2" "2012-04-05 19:29:50+01:00",2012-04-05 18:30:17,"Reedy","reedy@wikimedia.org","Making https svnroot point to https viewvc, not https viewvc to https viewvc, as that wouldn't replace anything Change-Id: Ibd7fe17e82c222c97010e468cec09ddc9aab0120 ","c2" "2012-03-29 13:13:23+00:00",2012-04-04 18:00:31,"Daniel Kinzler","daniel.kinzler@wikimedia.de","trigger http error when non-text content is requested using action=raw ","c2" "2012-03-23 21:23:38+00:00",2012-03-23 21:23:39,"Hashar","hashar@free.fr","Merge ""http->https""","c2" "2012-03-23 22:05:08+01:00",2012-03-23 21:05:08,"Raimond Spekking","raimond.spekking@gmail.com","http->https Change-Id: I300f05ea4eb273bfa57192e58075bb027c6a02c8 ","c2" "2012-03-20 05:17:40+00:00",2012-03-20 05:17:40,"Daniel Friesen","dantman@users.mediawiki.org","Commit the cryptrand project worked on in git: - MWCryptRand: A new api for generating cryptographic randomness for security tokens. Uses whatever cryptographic source is available and if not falls back to using random state and clock drift. - wfRandomString - A simple non-cryptographic pesudo-random string generation function to replace wfGenerateToken which was written pretending to be secure when it's really not. - Core updates to use MWCryptRand in various places: -- user_token generation (to do this we stop generating user_token implicitly and only generate it when needed to avoid depleting the system's entropy pool by reading random data we'll never use) -- email confirmation token generation -- password salt generation -- temporary password generation -- Generation of the automatic watchlist token -- login and create user tokens -- session ids when php's entropy sources are not set -- the installer when generating wgSecretKey and the upgrade key ","c2" "2012-03-07 02:43:46+00:00",2012-03-07 02:43:46,"Krinkle","krinkle@users.mediawiki.org","[jquery.textSelection.test] disable caretTest per bug 34820 * Right now it's causing testswarm clients to have to this test 3 times, and if until bug 34820 is fixed there is no point in clogging up testswarm with it, making all IE columns uselessly red and making it harder to detect an actual regression ","c2" "2012-02-28 00:14:33+00:00",2012-02-28 00:14:33,"Tim Starling","tstarling@users.mediawiki.org","Fix exception from list=recentchanges rcprop=loginfo: update for new log system ","c2" "2012-02-20 00:42:24+00:00",2012-02-20 00:42:24,"Daniel Friesen","dantman@users.mediawiki.org","Followup r111891; Update the test to also make sure things like http-equiv and rel=stylesheet don't link through. And update the sanitizer code so that bad and tags show in proper plaintext when tidy is enabled just like they do when not. ","c2" "2012-02-11 23:46:37+00:00",2012-02-11 23:46:37,"Thomas Gries","wikinaut@users.mediawiki.org","Aashish's fix for bug33997 (SpecialPasswordReset does not always has the correct returnto= page on the login / create account portlet and returns to SpecialPasswortReset instead to Main page ) ","c2" "2012-02-07 08:07:28+00:00",2012-02-07 08:07:28,"Daniel Friesen","dantman@users.mediawiki.org","(bug 34237) Regenerate an empty user_token and save to the database when we try to set the user's cookies for login. This allows the entire user_token column to be regenerated after a leak by running `UPDATE user SET user_token = NULL;` and letting the user_tokens be regenerated as users try to log back in. ","c2" "2012-01-27 21:16:47+00:00",2012-01-27 21:16:47,"Sam Reed","reedy@users.mediawiki.org","Yay, https ","c2" "2012-01-02 14:38:19+00:00",2012-01-02 14:38:19,"Chad Horohoe","demon@users.mediawiki.org","Revert r107042 (bug 32219, make InstantCommons protocol-relative) and do it properly + release notes. apibase is used for fetching content from the server as well as determining description pages, so should use a full-qualified protocol when the site's in https. ","c2" "2011-12-22 23:12:44+00:00",2011-12-22 23:12:44,"Brion Vibber","brion@users.mediawiki.org","Add comments explaining that the funky multiple Location headers stuff is a CURL artifact, and that the code will need updating if bug 29232 is done (high-level handling of http redirects) Followup r94881, r106948. ","c2" "2011-12-14 00:38:21+00:00",2011-12-14 00:38:21,"Brion Vibber","brion@users.mediawiki.org","Add BeforePageRedirect hook to OutputPage, allowing extensions to override redirect output. This is needed by MobileFrontend to normalize some redirects to the mobile site, such as on login. ","c2" "2011-12-13 23:54:27+00:00",2011-12-13 23:54:27,"Brion Vibber","brion@users.mediawiki.org","Update mediawiki & viewvc links on Special:Version to https ","c2" "2011-12-07 23:54:51+00:00",2011-12-07 23:54:51,"Jeroen De Dauw","jeroendedauw@users.mediawiki.org","add since tag; please do this if you add new public methods, it avoids bugs and hassle for other people ","c2" "2011-11-26 18:05:51+00:00",2011-11-26 18:05:51,"Raimond Spekking","raymond@users.mediawiki.org","More protocol relative links, reported by OsamaK@translatewiki.net (openid.net supports HTTPS) https://translatewiki.net/wiki/Thread:Support/About_MediaWiki:Openidlogininstructions/ar ","c2" "2011-11-24 08:41:57+00:00",2011-11-24 08:41:57,"Daniel Friesen","dantman@users.mediawiki.org","Modify maintenance/dev/ router code to fix the bug where post data gets discarded and you can't login inside the dev environment. ","c2" "2011-11-19 17:04:13+00:00",2011-11-19 17:04:13,"Antoine Musso","hashar@users.mediawiki.org","Bug 32397 - #userlogin is too narrow Patch by A. D. Bergi ","c2" "2011-11-16 23:55:40+00:00",2011-11-16 23:55:40,"Brian Wolff","bawolff@users.mediawiki.org","revert r103396 (breaks unit tests) - In lots of these places $u is undefined (for example, of a user doesn't specify a name, we havn't created a user object yet at the time of that check). Probably need to do something like create a second hook for loginAuditUserTotallyFailed or something. ","c2" "2011-11-14 10:34:23+00:00",2011-11-14 10:34:23,"Sam Reed","reedy@users.mediawiki.org","Followup r102910 Make the link to the MW page https only ","c2" "2011-11-14 09:13:58+00:00",2011-11-14 09:13:58,"Roan Kattouw","catrope@users.mediawiki.org","(bug 29854) Store protocol-relative links twice in the externallinks table, one with http: in el_index and once with https: . Modified patch by Brad Jorsch ","c2" "2011-11-13 21:42:57+00:00",2011-11-13 21:42:57,"Sam Reed","reedy@users.mediawiki.org","Bug 32379 - DatabaseError.php is hardcoding http Also tidy up a couple of returns (per others in method, and/or parents) ","c2" "2011-11-11 03:40:13+00:00",2011-11-11 03:40:13,"Daniel Friesen","dantman@users.mediawiki.org","Update xcache url since the old url redirects to the lighttpd redmine homepage instead of anything related to xcache. ","c2" "2011-11-05 19:51:05+00:00",2011-11-05 19:51:05,"Alexandre Emsenhuber","ialex@users.mediawiki.org","* Made OuputPage::showPermissionsErrorPage() show a different messages for 'read', 'edit', 'create' and 'upload' actions to saying ""You need to log in to do this action"" when 1) The user is not logged in 2) The only error is a permissions error (no block or something else) and 3) The error can simply be avoided by logging in * This replaces OuputPage::loginToUse() functionnality, made it simply throw a PermissionsEror exception and updated all calls in core * Same for the check in SpecialUpload::execute(), EditPage::userNotLoggedInPage() and EditPage::noCreatePermission() * Throw the same exception in EditPage::attemptSave() whether the user is logged in or not and let OuputPage::showPermissionsErrorPage() decide which message to display * Replaced call to deprecated OutputPage::blockedPage() in SpecialUpload * Displayed messages are the same as now, except the title is always ""loginreqtitle"" * 'nocreatetitle' and 'uploadnologin' messages are still used by extensions, so I kept them, but the message 'whitelistedittitle' is not used anymore and has been removed ","c2" "2011-10-24 09:32:33+00:00",2011-10-24 09:32:33,"Antoine Musso","hashar@users.mediawiki.org","test {{SERVERNAME}} with relative URLS bug 31176 mentionned an issue with {{SERVERNAME}} returning the full URL instead of servername when using relative URLs (//localhost). The fix was made by r98193. This patch test three different URL protocols (http, https & relative) and check we return the expected 'localhost'. ","c2" "2011-10-18 14:08:48+00:00",2011-10-18 14:08:48,"Alexandre Emsenhuber","ialex@users.mediawiki.org","* Use local context instead of global variables * Pass the context between Special:Userlogin and Special:ChangePassword when calling the other one ","c2" "2011-10-03 10:27:23+00:00",2011-10-03 10:27:23,"Roan Kattouw","catrope@users.mediawiki.org","(bug 31320) CentralAuth uses http URLs for autologin images when logging in over https. Renamed WikiReference::getUrl() to getCanonicalUrl() (but kept the old name as a back compat alias), and added getFullUrl() which returns a URL built using $wgServer rather than $wgCanonicalServer, which means it'll be protocol-relative if the wiki is configured for that. ","c2" "2011-10-02 20:58:15+00:00",2011-10-02 20:58:15,"Roan Kattouw","catrope@users.mediawiki.org","Followup r98707, r98713: check for blankness, not nonexistence. Since r98713 the -https message always exists, so the check was broken ","c2" "2011-10-02 20:02:35+00:00",2011-10-02 20:02:35,"Roan Kattouw","catrope@users.mediawiki.org","(bug 31293) If Special:Userlogin is loaded over HTTPS, display MediaWiki:loginend-https instead of MediaWiki:loginend, if it exists ","c2" "2011-10-02 16:50:52+00:00",2011-10-02 16:50:52,"Derk-Jan Hartman","hartman@users.mediawiki.org","Port r51457 from monobook to modern, simple and Vector. See also Bug 18207 Takes care of disappearing symbol when clicking extiw links, and triggering the external link and https lock icon on internal links. ","c2" "2011-09-27 19:21:53+00:00",2011-09-27 19:21:53,"Roan Kattouw","catrope@users.mediawiki.org","(bug 31191) Followup to r90934: do this in the successful login code path too. The bug didn't surface in most cases because the user is redirected immediately after a successful login, except when CentralAuth stops that from happening. ","c2" "2011-09-20 15:33:17+00:00",2011-09-20 15:33:17,"Roan Kattouw","catrope@users.mediawiki.org","Followup r97623: some fixes for RTL in IE70Fixes.css: * Remove useless .rtl #bodyContent a.external rule, already handled by CSSJanus * Flip the div#column-content div#content hack in RTL mode so the content area doesn't end prematurely on the left * Fix display of the user icon next to the login link or user name * External link icons are still broken in IE7+RTL, but they were already broken in 1.17 and are also broken in Vector ","c2" "2011-09-14 17:48:10+00:00",2011-09-14 17:48:10,"Ian Baker","raindrift@users.mediawiki.org","Switched from prepending http for protocol-relative $wgUploadStashScalerBaseUrl to wfExpandUrl() Followup to r96934 ","c2" "2011-09-07 03:25:11+00:00",2011-09-07 03:25:11,"Daniel Friesen","dantman@users.mediawiki.org","Move the vector styles for the user login form into commonContent.css The vector styles are very generic and fit well as the common style. With a minor tweak to MonoBook (which actually partially fixes a bug in the signup form on Wikipedia) this style fits in perfectly without conflicting with MonoBook's styles. ","c2" "2015-08-29 01:16:54+02:00",2015-09-08 14:43:06,"Timo Tijhof","krinklemail@gmail.com","resourceloader: Don't create empty objects for every module For modules without one or more of 'scripts', 'styles', 'messages' and 'templates'; don't needlessly create empty placeholder objects. Except for 'scripts', these were already handled conditionally. Bug: T105162 Change-Id: Ic1b3b09474e0b50b438b111a4f62368ceab4e732 ","c3" "2015-07-01 01:44:12-06:00",2015-09-04 22:42:32,"Brian Wolff","bawolff+wn@gmail.com","Use system default location for cafile when using php fopen. Up to 5.5, PHP does not accept any certificates if cafile/capath is not set. (From 5.6 it uses the system default CA budle, which is going to be a better choice than anything we can guess.) So try to guess the location of the system default CA bundle. Won't work on windows, but that's a lost cause anyway because PHP (pre-5.6) can't handle the windows CA file format. Bug: T75203 Change-Id: I07736c150fe0783e09d297395ed25adf335edbd3 ","c3" "2015-07-01 02:15:39-06:00",2015-08-30 01:47:50,"Brian Wolff","bawolff+wn@gmail.com","Workaround fopen lack of SubjectAltName support for instantCommons Hacky work around, where on php < 5.6.0 where SubjectAltName is not supported, if a request to commons.wikimedia.org fails, retry the request but telling php fopen wrapper to treat it as if it came from en.wikipedia.org for validation purposes, since as of c02fab71422a that's what the common name of the cert will be. In the ideal world, everyone would just have curl installed. I know this is super hacky, but I'd really like instant commons to work out of the box even without curl installed. Note: I'm basing the php 5.6 part on documentation, I have not tested this with a copy of that version of php. Bug: T75199 Change-Id: Ibde59be61a5b3d7cd5397ba352dce9be11e1b06f ","c3" "2015-08-07 02:16:48+00:00",2015-08-07 15:37:38,"Gergő Tisza","gtisza@wikimedia.org","Log human-readable login status Bug: T91701 Change-Id: Ia73fcc21321990befb1d866f76102b24d67adbfa ","c3" "2015-04-21 08:33:40+00:00",2015-07-28 22:31:07,"Gergő Tisza","gtisza@wikimedia.org","Track key authentication metrics Logs a 'login' event for logins via Special:UserLogin and API action=login. Does not log for implicit login after account creation and for autologin (e.g. based on an active CentralAuth global login). Logs an 'accountcreation' event for account creation via Special:UserLogin/signup and API action=createaccount. Does not log for autocreation. Both successful and unsuccessful attempts are logged, except for failures that throw exceptions (internal errors + some permission errors). Bug: T91701 Change-Id: I101b11d05400b073065da10f1e537412309d9102 ","c3" "2015-07-08 07:39:52+00:00",2015-07-28 22:24:00,"Gergő Tisza","tgr.huwiki@gmail.com","Log errors in Http::request() Instead of silently discarding errors in server-side HTTP requests, log them to a 'http' channel. Make ForeignAPIFile::httpGet() (which sort of reimplements Http::get()) log to the same channel, for consistency. Bug: T103043 Change-Id: Ibf552e22adc7fde4a751f92e92dad6ceba2f335c ","c3" "2015-07-24 07:05:57-06:00",2015-07-24 13:11:11,"Brian Wolff","bawolff+wn@gmail.com","The http-invalid-url message has a parameter, so send it Currently was outputting raw $1 to user. Change-Id: If1d10270f4d446c4d1703457903034e8356c1503 ","c3" "2015-07-07 18:51:27+02:00",2015-07-16 15:28:00,"Florian","florian.schmidt.welzow@t-online.de","Allow extensions to add a banner to UserLogin and CreateAccount special pages Some extensions, e.g. MobileFrontend, customize the UserLogin and UserCreate special pages. This change adds the possibility to add some HTML after the warning and/or error messages are printed to the output. This will be used in MobileFrontend to get rid of the own userlogin template. Bug: T87261 Change-Id: Ia81f7c52f08e8dcc73ac751432560c4077d4bd39 ","c3" "2015-07-13 23:07:02+00:00",2015-07-13 23:07:02,"Legoktm","legoktm.wikipedia@gmail.com","Revert ""Add 'AuthPluginStrict' log to identify users who are unable to authenticate"" Does not work as it will also log failed login attempts due to a wrong password. This reverts commit 9a97a7530f2a637cbb95603cfa4e0b51da753207. Change-Id: I6abd19da4e6939315a7fe6f7debe5227b68d38a7 ","c3" "2015-06-28 20:03:00+02:00",2015-06-28 18:03:00,"umherirrender","umherirrender_de.wp@web.de","Log http error in ForeignAPIRepo::httpGet This makes at least the ""SSL certificate problem: unable to get local issuer certificate"" visible. Change-Id: Icf0658b5e9f7ac9c58f98291345442f8e405435f ","c3" "2015-06-25 23:09:52-07:00",2015-06-26 07:32:36,"Aaron Schulz","aschulz@wikimedia.org","database: Make LoadBalancer not yield DB objects that hopelessly lost the connection * This is useful if the first slave picked went down and others can be used, especially in longer running scripts. * A possible improvement to this would be to eventually allow retries by removing the bad handles from the load balancer, since isOpen() will never change from false. This would only be useful for very very long running CLI scripts and is probably an edge case for now. Change-Id: Iecfc4004b4b2289907a4645b431de19198790d6c ","c3" "2014-06-21 15:01:52+01:00",2015-06-23 23:31:20,"Sam Smith","git@samsmith.io","Configure logged in session length independently * Add the $wgExtendedLoginCookies configuration variable, which defines the set of login cookies that can have their lifetime configured independently * Add the $wgExtendedLoginCookieExpiration configuration variable, which dictates when the extended lifetime login cookies expire * Default $wgExtendedLoginCookieExpiration to null so that the current behaviour is unaffected Bug: T68699 Change-Id: I0cc24524e4d7d9d1d21c9fa8a28c7c76b677b96c ","c3" "2015-06-02 18:27:23+01:00",2015-06-18 20:39:38,"Timo Tijhof","krinklemail@gmail.com","resourceloader: Enable module content version for data modules This greatly simplifies logic required to compute module versions. It also makes it significantly less error-prone. Since f37cee996e, we support hashes as versions (instead of timestamps). This means we can build a hash of the content directly, instead of compiling a large array with all values that may influence the module content somehow. Benefits: * Remove all methods and logic related to querying database and disk for timestamps, revision numbers, definition summaries, cache epochs, and more. * No longer needlessly invalidate cache as a result of no-op changes to implementation datails. Due to inclusion of absolute file paths in the definition summary, cache was always invalidated when moving wikis to newer MediaWiki branches; even if the module observed no actual changes. * When changes are reverted within a certain period of time, old caches can now be re-used. The module would produce the same version hash as before. Previously when a change was deployed and then reverted, all web clients (even those that never saw the bad version) would have re-fetch modules because the version increased. Updated unit tests to account for the change in version. New default version of empty test modules is: ""mvgTPvXh"". For the record, this comes from the base64 encoding of the SHA1 digest of the JSON serialised form of the module content: > $str = '{""scripts"":"""",""styles"":{""css"":[]},""messagesBlob"":""{}""}'; > echo base64_encode(sha1($str, true)); > FEb3+VuiUm/fOMfod1bjw/te+AQ= Enabled content versioning for the data modules in MediaWiki core: * EditToolbarModule * JqueryMsgModule * LanguageDataModule * LanguageNamesModule * SpecialCharacterDataModule * UserCSSPrefsModule * UserDefaultsModule * UserOptionsModule The FileModule and base class explicitly disable it for now and keep their current behaviour of using the definition summary. We may remove it later, but that requires more performance testing first. Explicitly disable it in the WikiModule class to avoid breakage when the default changes. Ref T98087. Change-Id: I782df43c50dfcfb7d7592f744e13a3a0430b0dc6 ","c3" "2015-06-17 21:48:51+02:00",2015-06-17 19:48:51,"umherirrender","umherirrender_de.wp@web.de","Remove unused global from SpecialUserlogin.php Change-Id: Idbdc8829d84e7dcce6b396bca8f90d9cf7864e45 ","c3" "2015-03-28 18:01:27-07:00",2015-06-16 15:29:06,"Aaron Schulz","aschulz@wikimedia.org","Made User generally use DB_SLAVE by default * By default, users will load from the slave unless the thread did a recent DB write. This is to handle changes within a request. * ChronologyProtector should avoid staleness in common cases, and the CAS check on user_touched is a final barrier to block stale user object updates. * Note that passwords are not cached, so they hit the DB when ever needed. Passwords now load from slaves when possible, instead of the master. * This should get the code closer to handling user login and logged in users when the master is down. * Fixed loadFromId() when READ_LOCKING is used. * Also addressed TODO comment in load(). Bug: T92357 Change-Id: I0a8bdab720c19fe3fc2381799ae2e90ff09bb4cf ","c3" "2015-05-31 16:30:01+01:00",2015-06-14 02:27:17,"Timo Tijhof","krinklemail@gmail.com","specials: Simplify return logic of various SpecialUserlogin methods * Handle exceptional case before common case in makeLanguageSelector by using early returns. Better reflects the intended effect of the exception by making it harder to accidentally run code after the 'else' statement. Change-Id: I710a94adf22bc4e6dc539e12c69e4ba96bf1068c ","c3" "2015-06-13 18:29:15+01:00",2015-06-13 18:23:23,"Alex Monk","krenair@gmail.com","HTTPS-ify links to Wikimedia's sites in MW core source See https://blog.wikimedia.org/2015/06/12/securing-wikimedia-sites-with-https/ Ignoring SVN stuff because svn.wikimedia.org's SSL certificate has expired, and ignoring wgSharedUploadPath because T25122 wants to get rid of it. Also a couple of BZ -> phab changes Change-Id: I02fd23ac6c30a4a4c718e57d4dedbc693dd653c0 ","c3" "2015-05-25 03:00:33-07:00",2015-05-27 15:51:59,"Tyler Cipriani","tcipriani@wikimedia.org","Add login error browser test Change-Id: I19a7f708825d5f11859d8ea70db4cdde752df26c ","c3" "2015-04-06 10:40:15+02:00",2015-04-06 15:13:03,"Gilles Dubuc","gdubuc@wikimedia.org","Track request method in dbperformance.log This will allow us to avoid needlessly investigating master requests that only happen on POST (which is already what we want for multi-DC). Bug: T92357 Change-Id: Ia7437d00f5b89a8e318d85659d60e2f9f9f26149 ","c3" "2015-03-31 19:01:15+01:00",2015-03-31 18:28:44,"Timo Tijhof","krinklemail@gmail.com","resourceloader: De-duplicate $files in ResourceLoaderFileModule::getModifiedTime() lessc::allParsedFiles() always includes the main file we already know about. As such needlessly causing it to be queried multiple times. Change-Id: Icd2c11d93d6491664fcf58a18bfe6e2932689774 ","c3" "2015-03-26 10:59:30-07:00",2015-03-26 17:59:30,"Aaron Schulz","aschulz@wikimedia.org","Changed user login logic to use less expensive touch() method Change-Id: I5143c381e870d65a1c5bf4cf28ec4abe1bbf3bfe ","c3" "2015-02-11 04:13:54+00:00",2015-02-11 04:21:36,"Timo Tijhof","krinklemail@gmail.com","mediawiki.api.login: Include second HTTP request in abort() Change-Id: I52e81781b2caf330ddb920b3ce842903808b7df3 ","c3" "2015-02-11 04:08:49+00:00",2015-02-11 04:10:54,"Timo Tijhof","krinklemail@gmail.com","mediawiki.api.login: Chain then() instead of Deferred wrapping No need to wrap a promise and manually forwarding fail(). Using ""then()"" does this by default. Remove redundant 'data.login' assertion. API errors are already handled at this point. Handle login error before success to allow a clean function exit. Change-Id: I032226b1e2b362c61eb2c6de0c7f5ebe2ed25b7e ","c3" "2015-01-14 02:32:36+05:30",2015-01-20 13:54:26,"Sumit Asthana","asthana.sumit23@gmail.com","Templates:Captcha position modified,extend functionality added to QuickTemplate The ConfirmEdit extension presently inserts captcha in the header of Usercreate and Userlogin templates. The js,if enabled places the captcha before submit button. A separate 'extrafields' placeholder for captcha is added just before submit button in Usercreate.php so that captcha position remains consistent, even if js is disabled. An extend method added to QuickTemplate to append any data to existing field, rather than setting it with fresh data. Particular use for 'extrafields' in Usercreate and Userlogin. Bug: T85192 Change-Id: I82c68814e79cbc5aa250a308862c59fcbb6fd527 ","c3" "2015-01-16 14:39:00-08:00",2015-01-16 22:39:00,"jdlrobson","jdlrobson@gmail.com","Stop using mw-ui-big on login form buttons This is inconsistent with mobile and is one of the blockers from us using this form rather than our own on a mobile device. Also mw-ui-big is a terrible class name and we should be deprecating its usage. Change-Id: I56e93429431690cf1b9ef043620b36148e3b4a7a ","c3" "2015-01-15 10:30:14-08:00",2015-01-15 18:46:01,"Bartosz Dziewoński","matma.rex@gmail.com","Userlogin.php: Tweaks and corrections * Correct nesting of the block generating ""Forgot your password?"" link – it would be mistakenly only generated if the user could create an account. * Use ->escaped() rather than ->parse() for 'userlogin-resetpassword-link', as it is used inside a link and allowing wikitext could lead to undesirable side-effects. * Remove unused $extraAttrs variable. * Remove pointless 'size' => '20' for some fields (they are displayed full-width using CSS). * Remove pointless .mw-ui-block class, as its styles are always used for buttons in a VForm. * Prettify code for hidden fields generation. Change-Id: If749620bf2eaf58f815cae559383e1a1c842b870 ","c3" "2014-12-04 15:39:50+01:00",2014-12-31 17:40:59,"Derk-Jan Hartman","hartman.wiki@gmail.com","Only return CORS headers in the response as required - Split out responses of preflight and actual CORS requests - If the request is not CORS valid, don't set the CORS response headers Note that invalid CORS requests should not actually throw error responses, the client should simply not handle the response because the response does not have the right headers (it's a client side policy error not an http error). We do throw a 403 for a mismatch with the queryparam, but since that is 'outside' of the spec, that might be appropriate. Bug: T76701 Change-Id: Ib296c68babe5c0b380268ee7793b3d6d35b9c3e3 ","c3" "2014-12-22 15:53:39-08:00",2014-12-23 21:42:56,"jdlrobson","jdlrobson@gmail.com","Consolidate mobile and desktop designs for login form * Stop sign up button from being a button * Move password reset to bottom of form Bug: T85189 Change-Id: I175e9f515d962f9078845f25f9b96079819444c6 ","c3" "2014-12-12 21:14:36+01:00",2014-12-12 20:14:36,"umherirrender","umherirrender_de.wp@web.de","Pass config to UsercreateTemplate/UserloginTemplate Avoids: QuickTemplate::__construct was called with no Config instance passed to it Change-Id: Ibfa1885dbe5609f1458dc3022dd367eb17b614b1 ","c3" "2014-08-02 13:29:57+02:00",2014-12-12 02:38:43,"Sergio Santoro","santoro.srg@gmail.com","Fix case insensitive string comparison for http header names As of RFC 2616 sec 4.2, http header names are case insensitive. Change-Id: Ib72df2572f5a9c825c5b3ad7735126f3687aad79 ","c3" "2014-12-03 23:37:56-08:00",2014-12-05 19:36:45,"Ori Livneh","ori@wikimedia.org","Optimize how user options are delivered to the client We currently embed the full set of user options in a