[04:47:21] @bluemoon ( can someone ping him discord side i forget the numbers in his username) do you know if this is a bug https://meta.miraheze.org/w/rest.php/createwiki/v0/wiki_request/50000 the Purpose: option in the wiki form is prepended with a \n to the actual body reason instead of being its own JSON field [04:49:37] PixDeVl: That's on purpose. They're both lumped in to one database entry rather than being separate ¯\_(ツ)_/¯ [04:50:03] ... [04:50:06] no [04:50:08] no no no [04:50:09] agent [04:50:12] its the same string [05:01:27] The original purpose of this seems to have been for the original AI so it reads the purpose as well. A bit poor design for other things though. Maybe I should move it... [05:02:19] MAYBE [05:02:24] how does that even work [05:02:33] are they in the same column?? [05:03:35] Yes [05:05:48] the code splits the purpose off at runtime :) [05:06:22] no [05:06:24] no [05:06:28] nononononono [05:13:35] it is a poor design [05:15:09] i wish for death [05:15:34] as my first act as tech i shall right this grevious sin [13:42:35] Btw @rhinosf1 for the most part it seems like my config at Cloudflare overrides yours [13:43:27] HSTS was being set as preload; I've manually enabled HSTS and set 0 without preload (as a test), and my value immediately overwrote preload [13:43:34] (And for which I do not want preload) [13:43:34] hmm [13:43:35] ok [13:43:42] Now gonna set few months :-p [13:43:50] i mean for preload it kind of makes sense [13:43:55] cause that's domain wide [13:43:57] some make sense [13:44:10] And which means you probably should not set preload for custom domains [13:44:13] i know our security settings are applied [13:44:23] we set preload for custom domains [13:44:30] i could change that [13:44:52] And I've used origin rules to add few custom headers, and it also added just fine [13:45:25] And lol, they had the docs. [13:45:27] https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/saas-customers/product-compatibility/ [13:45:48] can't do HSTS as a config rule [13:45:57] Heh. [13:46:06] Maybe zone rule applies? [13:46:15] Then we're probably stuck there [13:46:29] Just tell people to manually enable HSTS yourself if you don't want preload [13:46:33] i guess override it if you have an issue and that works [13:46:36] ye [13:46:37] (0 works just fine) [13:46:43] most should want HSTS though [13:46:54] Yeah, but not preload. [13:47:07] That probably should be an informed and determined decision [13:47:13] probably ye [13:48:57] And I guess that explains why I see analytics data [13:49:06] (cloudflare side) [13:49:40] ye you will if you have orange cloud [13:50:33] Yeah, time to fix my secondary legacy domain… lol [18:48:18] [1/4] working on some @WikiBot stuff: [18:48:18] [2/4] From a site operator perspective, is `Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36 (compatible; wikibot-bumblebee/x.y.z wikibot/1.6.1; wikibot@digitaldragon.dev; +https://wikibot.digitaldragon.dev)` a clear enough User-Agent? Could do something simpler like `wikibot-bumblebee/x.y.z wikibot/1.6.2 (wikibot@digital [18:48:18] [3/4] dragon.dev; +https://wikibot.digitaldragon.dev)` but lots of sites like to block every user agent that isn't a browser. [18:48:19] [4/4] (debated whether this belonged here or in #offtopic so let me know if I should move) [18:49:01] the first agent is very clear and preferrable [18:50:25] is it preferred to use the former for non-api.php requests and the latter for api.php or same for both? [19:40:41] You can use either from a security perspective [19:41:11] We've had 1 report of a bot affected by the new AI setting @agentisai enabled but we can action any requests to assist if you're blocked [19:41:29] As long as it's readable and makes it clear who you are, it's fine [23:42:53] [1/2] https://discord.com/channels/407504499280707585/1306119543017701417 [23:42:53] [2/2] Still seems that some users are locked out of their accounts.