[15:57:35] Finally figured out Elasticsearch and CirrusSearch. TL;DR: don't use AWS Elasticsearch for CirrusSearch :) [16:58:13] Hi and thanks for the awesome MediaWiki. Would it not make sense to manage refs in Wikidata? I mean instead of havin N occurences of more-or-less complete ref occurrences, there was only one [17:00:30] I mean one ref instance across all of a Wikipedia or if you take it really really beyond then across all Wikipediae. I know about the and that's very nice too [17:01:01] Iamthehuman1: you might be interested in https://meta.wikimedia.org/wiki/WikiCite [17:02:28] Thanks legoktm. This is the same as what I was thinking [19:28:47] duesen: hi, there's a user in #mediawiki-visualeditor asking about search not working for locked down pages that the user should be able to access. Any chance you could say hi [22:45:01] is it possible to check $wg* settings on a particular public mediawiki install? I suppose not since some aren't suitable for being public? [22:45:18] Indeed [22:45:22] The API exposes some specifically [22:45:24] Beyond that, no [22:45:37] Well, some are exposed in JS sources etc too [22:45:43] ok [22:45:45] ah yeah [22:45:52] Imagine if you could check what $wgDBpassword was :) [22:46:02] how does that work again? mediawiki.config.get or some such [22:46:16] mw.config [22:47:05] ok yeah, mw.config.get() is perfect for this debugging [22:48:08] ok so what I'm trying to do is figure out why wikisource.org has wgULSPosition set to "personal" while ban.wikisource.org (just created) has it set to "interlanguage" [22:48:22] this _seems_ to all somehow derive from the master file at https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+/refs/heads/master/wmf-config/InitialiseSettings.php [22:48:40] but not in any way that I can understand :) [22:48:56] wgULSPosition [22:48:58] ffs [22:49:01] 'wmgULSPosition' => [ [22:49:01] 'default' => 'interlanguage', [22:49:01] 'special' => 'personal', [22:49:01] 'wikimedia' => 'personal', [22:49:01] 'betawikiversity' => 'personal', [22:49:03] ], [22:49:17] two of those are dblist, one is a specific wiki [22:49:23] dblist? [22:49:33] https://noc.wikimedia.org/conf/highlight.php?file=dblists/special.dblist [22:49:38] https://noc.wikimedia.org/conf/highlight.php?file=dblists/wikimedia.dblist [22:49:44] ok [22:50:14] Then $wmgULSPosition is assigned to $wgULSPosition in CommonSettings.php [22:50:26] sure [22:50:37] but wikisource isn't in either of those lists [22:50:46] Yes it is [22:50:55] sourceswiki is in special.dblist [22:50:58] which is why it' personal [22:51:06] er [22:51:07] ok [22:51:13] and then ban wikisource is just using "default" [22:51:15] how am I suppose to know that sourceswiki is wikisource? :P [22:51:27] ask? [22:51:30] it's been like that for years [22:51:35] naming things is hard [22:51:37] haha, ok [22:51:38] renaming them is harder [22:52:45] ok yeah, I see under wmgULSWebfontsEnabled (which is more important for banwikisource) [22:52:57] they are [code]wikisource except for sourceswiki [22:53:32] so I can make a phab task I guess if I want to be sure wmgULSWebfontsEnabled is turned on for that new site [22:53:46] almost certainly, yup [22:56:09] ok so for example on https://en.wikisource.org/wiki/Main_Page it's using interlanguage rather than personal. ULS docs say there should be "an icon near the header of interlanguage links" to get to ULS settings, but...? [22:56:25] I don't see anything [23:33:06] Where do I need to go to get support for the OATHAuth extension bundled into the MW core? [23:39:03] here, in theory [23:40:45] Let me paraphrase what I sent via the mailing lists: We enabled the extension after upgrading to 1.35.2 from 1.29.1, but then I started receiving complaints from users that they were getting prompted for a TOTP when they'd never set it up. I checked the database, and none of the IDs in the oathauth-users table matched any of them, not even my account which I had manually enabled 2FA on. [23:41:03] Is the ID field supposed to cross-reference user IDs? [23:41:13] And are there documented issues when combined with CentralAuth? [23:41:27] Possible [23:41:30] Possibly* [23:41:38] Did you set it up to work on a central database? [23:42:18] ie set $wgOATHAuthDatabase [23:42:50] Just double checked my settings, and yes, it's set to our main wiki. [23:42:51] The OATHAuth database might also be corrupted. This happened to us, and I had to go in and make manual changes using SQL, yuck [23:43:58] What I really don't understand is why I was able to set it up for my account and it functioned correctly, but again, none of the IDs matched my account ID (whether global or local) [23:45:11] the id in oathauth_uers should be the globaluser.gu_id [23:45:20] (that's how it works on wikimedia wikis) [23:45:35] Alright, let me do some more checks [23:47:25] Okay, that matches up with my account [23:47:30] So that's at least good [23:50:42] I do notice that there's an entry with an ID of 0 [23:50:47] Surely that's a bug? [23:51:11] possibly [23:51:14] there's not one in WMF [23:51:19] So unless you can reproduce it... [23:51:51] Well, I didn't necessarily mean an inherent bug in the software, just a quirk from our setup [23:52:01] What I really mean is that there shouldn't be an ID 0 [23:52:20] ID 0 in other user context is an anon [23:52:31] I'm not sure how an anon could have tried to enable 2FA [23:53:08] We did have some trouble with CleanupUsersWithNoId or whatever that maintenance script is called. I wonder if the two are related [23:53:11] I hit some issues with 0 running upgrades. I've no idea where it came from either, just heads up that it might rear it's head later [23:54:31] Am I able to safely delete that whole table and start fresh? [23:54:39] Well, not delete the table, but the data inside [23:54:45] Yup [23:54:58] As long as you tell your users that any 2FA they've setup is now invalid [23:55:29] Right. I disabled the extension a few days ago, so it shouldn't be a problem [23:55:40] I'll drop the data and re-enable, then we'll see what happens [23:55:47] It's more if they leave it in their app, and then set up another... And then get confusd which is which :) [23:56:13] Ha, a good point! I'll be sure to update our site notice and try to get our twitter guys on a post [23:56:49] By the way, we also had these issues where people's passwords stopped functioning post-upgrade. Is that normal? [23:57:09] Password resets did the trick, but I find it odd that they would just stop working [23:57:23] Maybe a change to the encryption algorithm between 1.29 and 1.35? [23:57:36] Hard to remember that far back... [23:57:59] But even if it did, we encode part of that sort of info in the password stored in the database [23:58:19] there'll be a prefix of like :pbkdf2:sha512:128000:64: [23:58:52] Maybe I should ask this: with CentralAuth, do you log into a separate, global account or do you log into the local account and then get attached to your global based on data in the CAuth db? [23:59:25] If a globaluser row exists, that is used for auth-y stuff over the local row