Page MenuHomeMiraheze

Improve CentralAuth performance or create our own Login extension
Open, LowPublic

Description

Says it on the tin. We have hit CA limit and need to either improve the performance for large wiki farms or build our own login extension.

Event Timeline

PlanToSaveNoWork renamed this task from Improve CentralAuth performance or create our own Login extension to The plan to save Miraheze won't work because there are not enough seriously dedicated people. Time to leave Miraheze yoo hooo hooo. I tell you leave now or it will be a disaster!!The plan to save Miraheze won't work because there are not enough seriously dedicated people. Time to leave Miraheze yoo hooo hooo. I tell you leave now or it will be a disaster!!.Aug 9 2023, 17:44
PlanToSaveNoWork updated the task description. (Show Details)
RhinosF1 renamed this task from The plan to save Miraheze won't work because there are not enough seriously dedicated people. Time to leave Miraheze yoo hooo hooo. I tell you leave now or it will be a disaster!!The plan to save Miraheze won't work because there are not enough seriously dedicated people. Time to leave Miraheze yoo hooo hooo. I tell you leave now or it will be a disaster!! to Improve CentralAuth performance or create our own Login extension.Aug 9 2023, 18:54
RhinosF1 updated the task description. (Show Details)
RespectMat renamed this task from Improve CentralAuth performance or create our own Login extension to We demand respect and honesty! Stop lying to us and saying everything is swell and your working hard. Instead of telling us why don't you SHOW US with actual FACTS and ACTIONS. People should just leave this swamp unless the management promises to actually help which they are not doing they are just disrespecting us users and think they are better than us .Oct 23 2023, 10:19
RespectMat updated the task description. (Show Details)

@Paladox What bottlenecks are we hitting in right now, if any, in terms of performance? It may just have been the old hardware not being up to snuff.

@Paladox What bottlenecks are we hitting in right now, if any, in terms of performance? It may just have been the old hardware not being up to snuff.

CentralAuth makes a lot of DB queries. I think we should do some tests of how many are made for certain CA actions and see if any are useless or could be better cached.

Pages like Special:CentralAuth are never going to load on accounts with lots of attached wikis.

Also, it's kinda broken and pants. SUL2 is slowly falling apart as browsers increase security rules.

Pages like Special:CentralAuth are never going to load on accounts with lots of attached wikis.

This is likely because of it retrieving edit counts and group membership information on all wikis.

This data is coming from the function CentralAuthUser->localUserData() (https://github.com/wikimedia/mediawiki-extensions-CentralAuth/blob/b9dd57ed1f34cb397702fdc111ec786fce88cabe/includes/User/CentralAuthUser.php#L2707), it does multiple queries per wiki.

This is called in in CentralAuthUser->queryAttached() (https://github.com/wikimedia/mediawiki-extensions-CentralAuth/blob/b9dd57ed1f34cb397702fdc111ec786fce88cabe/includes/User/CentralAuthUser.php#L2593). This function loops over every wiki and calls localUserData for each wiki. It is very easy to see what goes wrong here when one is attached to many wikis. This serves to highlight the fundamental flaw of our use of CentralAuth: it is made for Wikimedia, where it is not possible for one to potentially be attached to over 8000 wikis, like here.

Also, it's kinda broken and pants. SUL2 is slowly falling apart as browsers increase security rules.

We'll do the same as Wikimedia is likely to end up doing, just have logins be made at loginwiki, remove SUL2 concepts entirely from the codebase to avoid setting third-party cookies and use redirects to prove to local wikis that an account is globally logged in, like the rest of the modern web.