[03:21:57] I got to remind them about the central user page issue [09:21:55] @atxatx [09:22:05] @felenov maintainer is in this server [09:28:41] @Infrastructure Specialists: any reason we don't have DNSSEC on? [13:34:06] hmm, nameservers for miraheze.org are via cloudflare, so, I assume it's a cloudflare option that has to be enabled [13:36:00] doesn't appear to be something that can be done via puppet [13:37:38] https://developers.cloudflare.com/dns/dnssec/ [13:43:04] @ltdk GDNSD doesn't support DNSSEC [13:43:16] I was asking infra in case anyone has it off for a reason [13:43:20] I suspect not [13:43:24] But I can't mind read [13:43:40] yeah, but I don't think GDNSD is being used directly; like I said, NS servers for miraheze.org point to cloudflare [13:44:09] @ltdk GDNSD is our old method of DNS. It is still used for all custom domains [13:44:15] ahh, that makes sense [13:44:18] Unless it's one of the few using cf-lb [13:44:25] And also what we used legacy [13:44:36] I do think it'd be worth migrating then, if it doesn't support dnssec [13:44:44] I would like to switch DNSSEC on for wikis that do go through cloudflare [13:45:08] Because I don't see any reason to have it off for the cloudflare nameservers [13:45:12] yeah [13:45:27] I was under the impression that cloudflare was mirroring gdnsd or something, which in hindsight doesn't make much sense [13:46:53] Custom domains will either use ns1/2.miraheze.org [13:47:13] Or point to mw-lb.miraheze.org/.WikiTide.net [13:47:21] a very select few use cloudflare [13:47:41] Everything on *.miraheze.org should pass from cloudflare [13:47:58] uniformity would make a lot of sense [13:48:39] [1/3] mine for example it is [13:48:39] [2/3] seems to be set in the lunar new year [13:48:40] [3/3] https://cdn.discordapp.com/attachments/1006789349498699827/1245373241715986546/D.png?ex=665883b6&is=66573236&hm=4bd4213104366122c7ec4d72557a98eeffcc47c63d9185124655da5fee95113a& [13:49:35] We don't have cloudflare for saas working well enough we can roll it out to all custom domains [13:49:51] yeah, also makes sense why it's not uniform atm :p [13:50:18] You are not using cloudflare's CDN [13:50:49] You are using their DNS but that still passes through the legacy cache proxies [13:52:26] The cloudflare setup is not designed to be uniform with the legacy. It's designed to give us a lot of advantages. [13:53:53] [1/2] a technical question, how does Miraheze work around this? My wikis' ManageWiki does not show descriptions for extensions that are not loaded. Is it loading the extensions' system message file somewhere? [13:53:54] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1245374561860718692/image.png?ex=665884f1&is=66573371&hm=f8151390d22c1f9364daee0458ad5a6828b8f3f1c6011d39460b18487a8c5c85& [13:55:10] @bluemoon0332 [14:13:04] Descriptions for ManageWiki extensions are pulled from their description in extension.json [14:13:46] if the extensions aren't in the folder they should be then it can't find the description. [15:10:06] minor clarification: the extensions are able to be accessed by managewiki (which is how they can get the name & description message), but because the code isn't actually loaded, the actual contents of the description can't be displayed and only the message name is shown [15:10:18] which is why you see stuff like `uwcreatepage-desc` instead of the actual description [15:11:32] @ltdk what are you clarifying ? [15:12:31] "if they're not in the folder they can't find the description" is technically incorrect; they're in a folder that managewiki knows how to find, but because they're not in the extensions folder, the messages aren't loaded [15:13:17] like without knowing where the extensions are they can't be enabled [15:13:30] ManageWiki doesn't auto populate the available extensions from any folder [15:13:47] I mean, that also makes sense [15:14:06] I didn't think that it would have a separate set of files for each wiki, and it would just selectively enable extensions depending on the wiki being loaded [15:14:21] if you're unsure, ask a question [15:14:26] Don't make statements [15:14:53] I mean, the "a folder versus the folder" part shouldn't have been stated, the fact about it being not loaded, rather than not found, was a statement that is true [15:15:27] We don't load extensions on every single wiki [15:15:31] correct [15:15:41] So if it relied on the loading of extensions, it would never work and it does for us. [15:15:57] So actually I'm not sure what you're saying [15:16:44] the question was: extensions don't show descriptions if they're not loaded. can they do this? answer: managewiki only loads extensions.json, not the actual code that contains the messages [15:17:00] my clarification was that it's not that managewiki can't find the code that contains the messages, but rather, it's choosing not to load extensions that are not used [15:17:31] Okay, actually that's not true [15:17:35] At least not for us [15:17:39] oh? [15:17:49] We don't have an individual message cache for every wiki [15:18:18] huh, but wouldn't that be required since you can have custom messages? [15:19:10] I was under the impression you could just make MediaWiki-namespace pages and use those as messages, but I could have misread the documentation [15:20:18] Yes you can [15:20:36] Mediawiki namespace takes precedence over the message cache [15:20:50] ahh, so that was where I was misunderstanding [15:20:51] The message cache is based only on source code [15:20:59] got it [15:21:17] you are right I should not make statements of things I'm not sure of, although in this case I thought I was sure and was actually misled [15:21:57] you could have easily worked that one out from our own setup. It would fail on every Miraheze wiki if what you were saying was true. [15:22:10] @suzuneu is talking about their own dev setup [15:22:27] ah, fair [15:23:06] either way, sorry for the noise [15:45:17] I've created https://issue-tracker.miraheze.org/T12166 for @cosmicalpha and @orduin [16:01:16] Your statement is really incorrect. [16:01:37] Extension names will show up in Special:ManageWiki/extensions becasue the name is added to ManageWikiExtensions.php [16:01:52] if the extension isn't in the extension folder, the description will not be populated. [16:04:25] For the global user page, I am not able to debug locally with my setup. Do you have a test wiki with both Skin:Citizen and Skin:SkinJSON installed? [16:06:41] we don't have SkinJSON installed. [16:07:26] Is there any exceptions or logs related to that page? [16:11:40] Okay let me try something [16:11:47] looking now but idk what page it is [16:25:13] Hmm would you able to try the latest main branch? I have added a patch that might fix it [16:33:38] hmm I just tried to bump it but looks like it didn't want to budge cc @rhinosf1 [16:33:59] (I don't really know much about mwdeploy) [16:34:47] I think I just pushed the exact same version out lol [17:09:12] did it say anything? what did you run? [17:22:51] Yeah it said deployed and listed all the servers [17:23:09] Something like mwdeploy --upgrade-skin Citizen --servers=all [17:23:12] Or something like ghat [17:32:10] @originalauthority full output? [17:32:38] Im afk so idk rn but ill get it when im home [17:33:03] actually no [17:33:06] https://github.com/miraheze/python-functions/blob/master/miraheze/mediawiki/mwdeploy.py#L439-L442 is annoying [17:33:12] that isn't using run_command [17:34:48] It was upgrade skins [17:35:04] urgh [17:35:09] it's same on skins [17:35:19] i'm not actually sure why they are seperate functions [17:35:28] I need to clean that up [17:35:39] os.popen is doing writes without showing it's doing them [17:35:41] which is bleh [17:36:20] i'm away Thursday - Monday [17:36:25] I will fix it next week [19:55:02] So for the global user page, it seems that the patch does not fix it as well 😦 I'm out of ideas of what might cause it [19:55:58] What extension is Miraheze using for global user pages? [19:57:40] Btw you might want to update Extension:TabberNeue as well, Citizen updated the styles to support the latest version for TabberNeue, so there will be mismatched styles if both are being used on the same page [20:00:18] you won't believe what this extension is called https://www.mediawiki.org/wiki/Extension:GlobalUserPage [20:00:50] I thought it was some combination of central auth magic with something else 😂 [20:00:55] That's engineers for you [20:01:01] We call thinks by what they do [20:01:26] I mean, CentralAuth + GlobalPreferences do help, but ultimately, you got what you asked for :p [20:03:27] like ultimately it doesn't matter whether the users are connected or not, just what shows up on the page for the wiki, and that's separate without the extension [20:04:39] what do you mean doesn't matter whether they are connected [20:05:26] I mean, the logins can be linked but the wiki pages aren't affected by the CentralAuth extension [20:05:56] GlobalUserPage assumes the username is consistent [20:06:04] It's a really dumb extension [20:06:15] yeah, I was reading the page after I linked, and it warns very strongly of XSS [20:07:01] it's honestly very weird that all of the different aspects of connecting users together are different extensions, but it's what happens when you have a bunch of different wiki farms that don't share all the same code together [20:08:30] GlobalUserPage is just doing an api call [20:08:47] yeah, copypaste the raw HTML contents of the page [20:08:59] It's cached obviously [20:09:19] right, but what's cached comes from the raw HTML, which is why there are warnings about XSS if you don't trust the wiki you're taking pages from [20:11:03] Yep [20:11:07] But we do [20:11:28] We should decide if we really need to send that through cloudflare though [20:12:01] do centralauth + the other extensions access the DB directly? I'd imagine they have to [20:12:16] Yeah [20:12:22] By how extensions work [20:12:30] They run with the core [20:12:32] CentralAuth does yes [20:12:43] api.php isn't cached [20:12:59] So sending it through cf just feels like adding latency [20:13:30] I mean, it's also just inherently uncomfortable [20:13:50] a lot of things would have to go wrong for it to be exploitable, but the fact that it's even an option is concerning [20:13:55] I assume it respects proxy config [20:14:18] So it's going mw -> bast -> cloudflare -> bast -> mw [20:14:32] That's 3 extra steps [20:14:45] For something localhost could always do [20:15:04] yeah, you could localhost api.php, or you could just pull directly from the DB if that's an option [20:15:50] since passing through api.php is itself another layer of latency [20:16:14] direct db isn't for GUP [20:16:29] It would be nice if it could use localhost though [20:16:46] ah, is CentralAuth not an actual extension but a code patch, then? [20:17:21] CentralAuth is an extension [20:17:51] A complex, weird and semi supported one [20:18:03] I mean, there's always the option to make GUP into one of those :p [20:19:16] GUP is an extension [20:19:21] It's just a dumb one [20:20:32] I don't think Ashley is on discord [20:20:38] You could ask them [20:20:41] They're friendly [20:37:41] @rhinosf1 thread [23:31:00] Oh. Lit [23:34:40] did something change with citizen? [23:35:03] [1/2] this used to have font and page size settings but now it's just the text "preferences" with nothing below it... [23:35:04] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1245520817333211136/image.png?ex=66590d27&is=6657bba7&hm=ebb6185251efb89d1f3c872dcb379c82d7b1d036bf572b18d0e85bea53f50cc3& [23:36:01] citizen was updated, so, there were changes [23:36:12] no clue if it's related to your issue though [23:40:00] probably is related as it was working normally yesterday before the update [23:42:03] yeah, just, will have to wait for someone who knows what changes were made to help debug the issue