[02:57:57] Can someone explain to me how we do root domain paths and use root domain for main page? For a friend [03:05:43] rewrites [03:06:21] Got that. Was trying to find where we implemented them in NGINX, only found the mediawiki stuff [03:13:40] is that in puppet at all actually [03:23:11] hacky rewrites [03:23:15] decode.php is a mess [03:24:07] no, because NGINX doesn't know about $wgMainPageIsDomainRoot or whatever it is [03:24:08] Oh so it is in mediawiki [03:24:15] everything is passed to decode.php to deal with [03:24:30] which is in /mw-config/initialise/somethingsomething [03:24:40] i've forgotten what the somethingsomething is [03:25:01] so that file has the important stuff [16:24:06] Was checking out [[mw:Extension:MigrateUserAccount]] that’s used on Weird Gloop, and looks like it doesn’t interfere with CA stuff. Y’all think it would actually work on MH? [16:24:07]

[16:24:17] If so, useful tool to have possibly [16:26:54] wiki.gg uses it too, but they don't use CA [16:32:16] It seems to work by checking if an account in the local database has an empty password field in the database, then having you put a token on your fandom UP to verify, then reassigning edits [16:32:20] I think it could work [16:32:28] When I have access I may test it on beta [16:38:31] Wouldn’t that enable account takeover? [16:39:28] Don’t think so? [16:39:43] It works on farms with a shared user table because it can detect what accounts exist across the farm but for CentralAuth, remember that user accounts are not shared on a single table so the extension wouldn’t be able to detect that an account already exists if one does [16:40:10] that also relies on a scraper creating dozens of shell accounts [16:40:34] I thought importing already did that ngl [16:41:08] It does not, it creates actors only but doesn’t create actual user accounts unless you link it to an actor ID with a valid user account [16:41:18] those would then need to be migrated globally and conflicts resolved between username collisions [16:41:25] You mean if an account with the same name exists somewhere else on the farm and not attached [16:41:26] Hm [16:41:27] Valid [16:42:11] user accounts are so messy [16:42:23] but it would be cool if a CentralAuth compatible version existed [16:42:58] Oh dang SecurePoll removed GPG [16:42:59] MigrateUserAccount does work with CentralAuth. [16:44:43] have you tested it out? [16:46:11] [1/5] The process with it is that [16:46:11] [2/5] - You fork a wiki with the grabbers, or some other way [16:46:11] [3/5] - you ensure that local accounts exist in the local user table (this is a requirement anyway, because even with centralauth each wiki maintains its own account table); they will have no password and it will be a stub account [16:46:12] [4/5] - MigrateUserAccount will allow you to reclaim the user account by going through the process which will allow the password to be set [16:46:12] [5/5] - Attach the account to centralauth like usual [16:46:21] yes [16:47:12] Well [16:47:40] I understood you made a new account(which would be attached to CA) and reassign the edits from the stub one [16:47:54] no, that isn't how it works [16:48:07] the stub account becomes the usual account after the migration [16:48:19] > Similarly to Extension:StubUserWikiAuth, this extension only works for users that have an empty password field on the database (the user_password field of the user table is empty), which usually comes from running the scripts in Manual:Grabbers. [16:50:25] [1/2] Yeah that’s a given but the concern is step two and three. You can create an empty user account but it won’t correspond to the global account because the passwords don’t match so you’ll have a global account that can’t be used on one wiki and a local account that cannot be used on all wikis except that one. [16:50:25] [2/2] The third step would be of concern if a grabber creates a local user (for example, “Example”) which exists both on Miraheze and on the old wiki. If you can verify you own “Example” on the old wiki, wouldn’t it reset the password on the Miraheze account and allow for account takeover? [16:53:41] [1/4] > You can create an empty user account but it won’t correspond to the global account because the passwords don’t match so you’ll have a global account that can’t be used on one wiki and a local account that cannot be used on all wikis except that one. [16:53:41] [2/4] No, because you set the password after the account reclaimed, at which point you set the password to the same password as the CA account and then the account can be merged by going through the same process as merging an account usually. [16:53:41] [3/4] > If you can verify you own “Example” on the old wiki, wouldn’t it reset the password on the Miraheze account and allow for account takeover? [16:53:42] [4/4] Potentially, yes. [16:53:47] Works != safe. [16:54:11] And if the user doesn’t set the same password, :p [16:54:40] I don't really know how CentralAuth handles attaching but iirc it won't let you attach an account where the password's don't match [16:54:59] Although, if it needs the user to have the password to the account of the same name globally that may stop the potential of takeovers [16:55:14] Got to be careful, since that can be a MFA bypass [16:56:40] When I meant works, I meant safe \:p [16:57:21] yeah so might not be the best for our setup then [16:57:36] but it would be interesting if a CentralAuth compatible setup could exist [16:58:32] Definitely [16:59:11] I mean does the imported account need to have a user entry [16:59:51] If we’re trusting the dump is correct could probably do the same with an actor entry alone and reassign to the real account the user makes normal [16:59:56] Or am I missing something [16:59:56] you can't attach a user account to CA if it first doesn't have an entry in the local user table [17:00:05] because there's nothing to attach [17:00:53] (note that CA attaches accounts based on username, actor id is irrelevant) [17:00:57] I’m not saying make a new one, I mean register like normal, then use the fandom:sub>User or whatever to find that user on fandom and do the same thing of giving the user a token to put in their UP [17:01:29] And if it’s verifies correctly replace the entry’s assigned to the >imported actor with the normal CA attached account [17:02:25] Although I assume there’s a reason they implemented how they did [17:03:00] [1/2] I guess its a moot point because the exploit relies on the username of the CA account being exactly the same as the username of the old account on whatever wiki (lets take Fandom in this instance), so you would need to know the password of the old account on fandom (since you can't have two accountss of the same name on fandom) so the possibility of taking over an account i [17:03:01] [2/2] s very slim i would think [17:03:45] Might be worth asking Jayden or Cook why they implemented like that [17:04:02] i'm confused about what you mean? [17:04:08] how else would it be implemented? [17:04:22] I love miscommunication [17:04:33] I am potntially misunderstanding what you mean but [17:05:03] As I see, the WG extension requires a grabber to make a local user account entry for each imported account, which then becomes the user account [17:05:47] My idea was to verify with just the local actor entry, then reassign to the actor of the normally created CA kosher account the user registers and verifies [17:07:08] Since it’s just reassigning edits on one wiki from an actor that didn’t have an associated User anyways, should be fine [17:07:29] I may be getting messed up too [17:07:33] [1/6] yes, so in this instance I don't necessarily think that the exploit could be used because [17:07:33] [2/6] - Lets say i fork a wiki, and it has a user named Example [17:07:33] [3/6] - theres an example user in the local table but it doesn't have a password [17:07:33] [4/6] - i create a global account named example with the intention of taking over that local account [17:07:34] [5/6] - i can't because there is no password for that local account so I can't merge it with central auth [17:07:34] [6/6] - i can reset that password on the local account via MigrateUserAccount, but it relies on me knowing the password of that account on the fandom wiki [17:08:22] Point two is the thing [17:08:33] As I understood, importing doesn’t create an account [17:08:36] It creates an actor [17:09:11] Is that the page [17:09:13] Idk [17:09:16] I need to check docs [17:09:20] correct, but an actor _must_ be associated with an account unless its an anon [17:09:40] there is a reference to the _user_ table in the actor_user field [17:10:07] tl;dr CentralAuth is cooked [17:11:03] That we knew yea [17:11:27] Actually [17:12:40] [1/2] > actor_user [17:12:40] [2/2] > A key to `user.user_id` of the user who made the action, or `NULL` for logged-out (IP) edits and for some mass imports. [17:12:45] @originalauthority [17:13:10] very ambigious [17:13:12] thanks mediawiki [17:13:32] We can check ourselves [17:13:47] Check the import log for a wiki that imported and check the database tables [17:14:01] well I guess thats fixed by the ceckbox which says "Attribute edits to local accounts where they exist" [17:14:18] Hm [17:14:38] i'm pretty sure using xml imports was never meant to be used to fork a wiki which is potentially why [17:14:40] Does that still create accounts for the others [17:14:58] Then What was lmao [17:15:01] i don't think importing creates accounts lmao [17:15:23] So [17:15:24] Good? [17:15:30] thats what the grabbers are for I guess; there's no in built mechanism to fork a wiki because nobody is forking wikipedia i guess [17:15:59] Too true.. [17:16:20] So imports maaaaay not create local accounts(?????6 [17:16:27] So my idea may work [17:16:32] I have no fucking idea [17:17:02] solution is to rewrite mediawiki in c# [17:17:15] Unfortunately I have too much of a skill issue to try and make an extension compatible with CA [17:17:28] How do you only work in the worst programming language La [17:17:45] C# is the goat among programming languages [17:18:04] Always screaming? [17:19:17] I want to look at MUA’s code [17:21:41] Also I been working on my bot but I don't think it will be useful because discord already has /ban /kick stuff so whats the point [17:22:04] The point to using dyno is case management really [17:22:14] !warn @pixldev nerd [17:22:25] Pretend that worked [17:23:17] I'm tryin to build a portfolio for applying for software engineering jobs but idk what to build [17:23:36] I’m going to finish some work, work on a mini project and then take a lot at MUA [17:23:49] If we can write our own version that plays nice with CA sick [17:24:20] I was gonna Work on something interesting but it’s in python [17:24:31] impossible [17:24:39] interesting and python are mutually exclusive [17:27:55] Ugh [17:28:05] It tangentially involves C [17:28:07] Happy? [17:28:13] ew [17:28:15] thats worse [17:28:35] C is such a weird language [17:28:42] the syntax is so poor (just like rust) [17:32:01] That may be the one take I can agree with you’ve made [17:32:21] Wait no [17:32:23] C++ [17:33:10] yeah that too [17:34:18] marginally better [17:34:27] i like how the C++ and C# logos are almost identicl lmao