[05:47:32] I'm currently having issue with login, as I tries to login into my account in an internet cafe, CloudFlare captcha prevent the login from going through as usual by putting the captcha ONLY after I submit my username and passwords [05:48:10] Once captcha is done, the CSRF token is already deemed dead by MediaWiki itself [05:48:40] Currently the only way I can login was to go straight to Login Wiki and login there [05:48:54] That's weird [05:49:07] Of course its alway those stupid LLMs from our networks providers... [05:49:45] Ping me your ip (both v4 + v6) [05:49:55] Will DM you [05:50:24] Alright, I can look in like half an hour [09:51:16] [1/2] Since Mirabeta is back online, anyone want to give this a try? [09:51:16] [2/2] I tested a few other skins that used to be broken (apex, nimbus, nostalgia, truglass), and they are no longer throwing errors now. [10:59:19] Done [11:02:54] Thank you! Medik is working fine on mirabeta, so I'll check it off. [11:43:19] I just realized that I got this wrong. Sysops used to have `editsitejs` and `editsitecss` by default, but these permissions were [removed in 2023](https://meta.miraheze.org/wiki/Special:Log?logid=916231). i18n XSS would allow sysops to edit sitewide js, which they normally can't do. [12:06:33] Better to find out now, than too late 😉 [12:17:46] And I realized that the thing I was implementing wouldn't be a security risk anyways because CSS pages in the MW namespace are restricted by editsitecss regardless of their content model [12:34:49] Are they, if they have the sanitized CSS content model? [12:35:09] Yes, there's a paranoia check for the .css suffix [12:35:19] Ah [12:36:08] [12:40:25] Though I dunno if relying on this particular check for security is a good thing but yolo [12:42:02] Does TemplateStyles require the title to end with ".css" though? [12:44:22] Hmm good point [12:45:16] I'll add that check to my ContentModelCanBeUsedOn handler [13:05:44] [1/2] i seem to have this long error [13:05:44] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1412423247919710218/image0.jpg?ex=68b83d27&is=68b6eba7&hm=6bc073ad0ca1c3f4fbcee81a071d13c439fc7217cd73bad21cdf1b777238254b& [13:05:53] [1/3] > `Refused to execute script from 'https://tagging.wiki/w/load.php?lang=en&modules=ext.CookieWarning%2CSimpleTooltip%2CeventLogging%2Cpopups%2Cpurge%2CstandardDialogs%7Cext.articleFeedbackv5.startup%7Cext.centralNotice.choiceData%2CgeoIP%2CstartUp%7Cext.centralauth.centralautologin%7Cext.checkUser.clientHints%7Cext.echo.centralauth%7Cext.embedVideo.overlay%7Cext.urlShortener.toolba [13:05:53] [2/3] r%7Cjquery%2Coojs%2Coojs-ui%2Coojs-ui-core%2Coojs-ui-toolbars%2Coojs-ui-widgets%2Coojs-ui-windows%2Csite%7Cjquery.articleFeedbackv5.utils%7Cjquery.client%2CtextSelection%7Cmediawiki.String%2CTitle%2CUri%2Capi%2Cbase%2Ccldr%2Ccookie%2CjqueryMsg%2Clanguage%2Crouter%2Cstorage%2Cuser%2Cutil%7Cmediawiki.editfont.styles%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%7Cmmv.boots [13:05:53] [3/3] trap%2Ccodex%7Coojs-ui-toolbars.icons%7Coojs-ui-widgets.icons%7Coojs-ui-windows.icons%7Cskins.citizen.scripts&skin=citizen&version=1m600' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.` [13:13:16] damn what were you even running on your page [13:13:43] Are you getting an error when you visit that link [13:14:03] I'm not but it could be the same case as yesterday [13:15:37] i'm also getting a normal JS file from the link, so this could be it [13:16:29] it's not [13:16:38] i think standarddialogs is the cause [13:31:15] It tries to load that script, Miraheze says nope not allowed and then it logs these errors [13:39:49] Probably Cloudflare [14:34:17] I'd recommend using Lighthouse locally instead [14:34:21] @snowfleaf [23:35:05] Is code like https://gerrit.wikimedia.org/g/mediawiki/extensions/ArticleFeedbackv5/+/bb8ee83d803b7e4a5aa1b80a4b71c89ac4871d7f/includes/ArticleFeedbackv5Hooks.php#57 supposed to work alongside ManageWiki, or do we have to manually grant those default rights to the groups via ManageWikiExtensions? [23:36:37] I'm assuming this is ran in an extension function? In which case ManageWiki has already passed the list of permissions back to MediaWiki so it should be fine for the extension to modify them at that point. [23:37:39] yup, an extension callback [23:37:43] It doesn't work for some reason though [23:38:15] The right (in this case `aft-reader`) is not granted to any group, which causes an exception when viewing Special:Watchlist [23:38:38] Oh [23:38:40] I see whats happening [23:38:58] No i don't actually [23:39:00] i read wrong [23:39:03] it shoudl be working hmm [23:40:09] I do see whats happening actually [23:40:14] No I don't [23:40:16] what the hell [23:40:22] lol [23:40:29] It works for me locally [23:40:30] those rights aren't defined in extension.json as availablerights [23:40:32] oh [23:40:35] pretty sure they are [23:40:41] oh yeah [23:40:43] https://cdn.discordapp.com/attachments/1006789349498699827/1412583048762884176/image.png?ex=68b8d1fb&is=68b7807b&hm=432b423a66af76c2eb07458963cfcca528cebca522a9072ef44d75ca27eab316& [23:40:45] I'm using gerrit to look thats why [23:40:49] ah [23:40:53] i need to go to bed lol i'm making it worse [23:42:32] Weird that it's not working with ManageWiki - I wonder if something else is the issue? once ExtensionRegistry calls that callback, $wgGroupPermissions should already be populated so it should be able to modify it at will (and ManageWiki won't touch it after this stage so its weird)