[00:13:48] Has anyone with an iPhone had issue with setting up an iCloud Keychain key with SUL webauthn? [00:18:43] what's the error i wonder [00:22:10] i can reproduce [00:22:18] strange, since it works on wikimedia wikis [00:22:50] (re icloud passkeys) [00:23:27] (just means that i have to use my Yubi key) [00:24:01] is your phone a bitch about reading the yubikey for that [00:24:21] Wondering if i file a phorge task or ask on WM tech places about this [00:24:24] i've never had any problem using it on my iphone [00:24:45] not quite sure on that one [00:25:04] no idea weather or not its an us issue [00:25:21] I usually have a very hard time reading passkeys from a yubi on my phone [00:25:38] the yubico app always works perfectly from a good distance for TOTP [00:27:32] i put my totp codes in cloud as then its a quick face/touch id to autofill [00:27:53] icloud* [00:28:24] wait wait wait [00:28:28] thats a thing? [00:28:31] .. [00:28:35] yup [00:28:37] huh.... [00:29:07] can you have webauthn and TOTP at the same time [00:29:18] yes [00:29:40] of course the site also has to support it [00:29:56] in our case its supported in MW 1.45+ [00:30:06] so you'll be able to after the upgrade [00:31:32] Oh [00:31:34] interesting [00:45:37] i checked on a different non MH wiki that uses close to the latest 1.45 commit of WebAuthn (only outstanding ones are i18n) and passkeys work fine [00:45:51] so seems like it might not be extension related [00:54:31] oh [00:54:43] its because wgWebAuthnLimitPasskeysToRoaming was set to true by @CosmicAlpha [04:02:45] @cosmicalpha Q, how does our mediawiki stack work with LDAP? I know LDAP wiki still exists but I recall there was uncertainty or something about the extensions? [04:29:12] i believe the extension for authentication is deprecated now [04:30:11] https://issue-tracker.miraheze.org/T10825 [04:30:16] see also: https://issue-tracker.miraheze.org/T10857 [04:44:53] do we still use it? [04:45:35] The extension was archived completely. I forked it and maintain it for now. So yes we still use it. [04:46:00] 😭 [04:46:06] https://github.com/miraheze/LdapAuthentication [04:47:02] No other extension is a replacement because no other allows changing passwords via it. Thats the only reason ldapwiki.miraheze.org even exists. [04:47:50] when are we gonna write a frontend to change your creds [04:48:00] Working on something. [04:48:54] (not writing from scratch but a software outside MW that needs some modernization for a puppet module first) [04:49:15] whichb one? [04:53:46] https://github.com/ltb-project/self-service-password [04:55:07] Also has a puppet module already: https://gitlab.adullact.net/adullact/puppet-ssp but probably won't work without some changes seeing as that one was last updated 6 years ago. But ssp itself is still maintained. [11:23:28] auth.miraheze.org/favicon.ico is returning a 500 for me [11:31:22] Probably [11:31:40] Auth isn't a real wiki [11:31:49] Although we could probably come up with a favicon for it [11:41:33] why not the default mh one? [11:48:52] We could [11:49:00] I still need to find what logic needs fixing too [11:49:04] And decide the best way [11:51:36] It comes from https://github.com/miraheze/puppet/blob/main/modules/mediawiki/files/favicon.php [11:52:08] I kinda wonder if it should just be rewritten to meta at the cf end to avoid cache duplication @blankeclair [12:12:01] i can do that [12:13:19] Go for it [12:19:14] redirected to https://meta.miraheze.org/favicon.ico 👍 [12:19:51] Redirected or rewritten [12:20:22] Redirected [12:20:28] Use rewrite @pskyechology [12:20:31] redirected; i can do a rewrite as well once you point out where they hide them [12:20:39] Avoids the extra request [12:20:46] oh it was right below redirects [12:20:48] blind [12:20:49] Should be in the url rules as an option [12:27:16] all good now [12:27:41] pissed that the so called url rewrite type does not allow for host rewrites [12:27:53] nooooo you have to do that in origin rules [12:28:40] Woo [12:28:57] Cloudflare has about a hundred types of rules and it's a terrible UX [12:29:02] It used to nice and simple [12:29:15] i too like to smoke crack when categorizing [12:29:41] It doesn't even need to done the way it is [12:29:51] I swear most UX/UI designers [12:30:03] Are clueless and have never used a website in their life [12:30:21] more like corporate is pushing for them to do something so they dont get fired [12:35:16] i was thinking nginx [12:36:17] free PR for thee [12:36:52] Earlier in the chain the better [12:36:59] fair [12:37:02] caching n all that too [12:37:51] Yup [15:59:18] recent changes feed on a wiki is miraculously missing one edit (that we know of, and like, completely, not because of any filtering or user being a bot, it), is it worth a Phorge ticket [15:59:38] love sending messages before finishing them because I hit Enter 😭 [16:00:34] anyways, just wondering if that's something worth a ticket. It's not showing up either in API nor on Special:RecentChanges and it's a very recent one [16:02:13] You will never know how many other things I did to your wiki! [16:02:46] what are the silly wikibot fellas up to [16:02:55] I don't know, Markus is hacking a wiki [16:03:02] that's his usual day I guess [16:03:05] might as well, certainly weird that it is missing [16:03:25] i dont remember us making a mediawiki parser eats your socks update [16:03:55] I bet it's related to SUL3 [16:04:01] alright, I'll do that, thanks [16:05:34] rather likely as we are currently facing issues with purging due to it [16:05:44] SUL3 is the evil sock monster as it turns out [16:07:40] [1/2] The missing edit was done in my name through an OAuth consumer. [16:07:40] [2/2] At that point I had never logged in on any Miraheze wiki since the SUL3 switch [16:08:19] oh that'd do it probably [16:08:41] cool, I'll add that to the ticket [16:12:29] Something was probably looking for my user in a place I didn't exist yet [16:13:56] My money is on CheckUser, it's always that extension when edits are missing from RC 🙃 [16:14:26] well, created a ticket. Don't think it's worrying enough to be marked as security, however I guess it might be in that category due to potential of abuse, even if I suppose it requires certain conditions to fulfill https://issue-tracker.miraheze.org/T14880 [16:14:52] it still appears in page history right [16:15:00] yes [16:15:06] and on player's contributions page [16:15:10] player's lol [16:15:12] user's [16:15:21] ok then it's not too concerning yet [16:16:04] and it did appear via DN https://discord.com/channels/407504499280707585/475350160428498964/1467178390326087781 [16:16:08] I love screenshots of stuff nit being there [16:17:18] Interesting, so it errored somewhere between the hook used by that feed and the creation of the recentchanges table entry [16:17:45] either way, I blame Markus for taking another 30 mines of my life, thanks [16:18:34] haha [16:18:44] Brb, crashing Wiki-Bot server for you to fix [16:19:31] Skye, do you know if we use E:WebAuthn or just OATH? [16:21:17] webauthn is a global e [16:21:36] The push to the recent changes table is done in a deferred update after the output is sent back to the client - I wonder if there was an error after that [16:22:01] It would have to be and we do know of at least 1 deferred update failing [16:22:22] if I could be arsed to setup SOCKS5 I would check graylog but meh [16:22:36] Api response was successful for that edit. Didn't get an error in Discord [16:22:44] yeah [16:22:56] the output is already flushed to the client before the deferred update runs [16:23:01] so you wouldn't know [16:23:14] Gotcha, I know WebAuthn was merged into OATH [16:23:28] Is there any evidence of this happening more than once [16:23:31] 'tis the problem with Deferred Updates, the request has already been responded to before they run, so any erorrs that occur aren't surfaced to editors [16:23:32] Not yet [16:24:01] I mean that's not really a problem [16:24:03] Does this roaming setting actually exist?? I can’t find anything on it anywhere, code search only brings up https://gerrit.wikimedia.org/g/operations/mediawiki-config/+/7d23c3f78982c249cf102141bb9d0f679c344b76/wmf-config/CommonSettings.php and no other results [16:24:03] i'll have a look in graylog now I suppose [16:24:42] Also, $wgWebAuthnLimitPasskeysToRoaming = true; is on Wikimedia too [16:24:44] it does but they removed it in master already iirc [16:24:44] Uuuuuugj [16:25:03] Note that I probably can't reproduce the edit anymore as I've logged in since [16:25:08] Still exists for us? [16:25:15] yes [16:26:23] @pixldev it exists in pre MW 1.46 versions of webauthn (pre merge into OATHAuth) [16:26:23] What about beta [16:26:33] 1.46 damn [16:26:50] https://www.mediawiki.org/wiki/Extension:WebAuthn# is really not clear [16:26:56] It used past tense [16:27:14] Passkeys would work, but UO wants to have it disabled until 1.45 at the very least [16:27:48] hmph graylog does not wish to load for me! [16:38:46] I see the request in graylog but nothing else hmm [18:23:40] Login to Phorge through Mediawiki Oauth seems to be broken since the SUL3 update. [18:38:29] ^ this is being looked at now [18:38:35] i was able to reproduce [18:44:59] might be a good way to solve the task backlog /s [18:45:40] https://issue-tracker.miraheze.org/T14882 [18:59:53] Odd, I think I did so yesterday and it worked [19:22:02] [1/2] hi [19:22:03] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1467238517309575198/image.png?ex=697fa7da&is=697e565a&hm=8f84fd32c1301a070606dfb750c5e473f76ee7f9789beb04ef056e6c8b8b9eb2& [19:22:09] keeps happening on https://forsaken.wiki [19:22:34] on POSTs especially [19:25:06] [1/2] this and really slow requests [19:25:06] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1467239284791574580/image.png?ex=697fa891&is=697e5711&hm=8789497b96a34184eec2117b43c30c2337890f6399a8e6079ae9e69588a98ff1& [19:43:00] I have fixed this now btw. [19:53:44] I am looking into this btw. [19:53:54] alr