One way could be to apply a GlobalBlock to the IP address used when a temp account is locked.

@Dreamy_Jazz Thanks for this idea.

If we think of temp accounts as being like fully registered accounts, then it makes sense that globally locking should work.

If we think of temp accounts as being like IP users, then global locks don't currently work for IP users (the concept makes no sense) so are we losing anything by them not working for temp users? In other words:

• If a temp user does something that would warrant a global lock, what would we do in the equivalent situation if an IP user did that same thing now?
• Could we still take that same action for the temp user?

This may be a duplicate of T19929: CentralAuth account locks should trigger global autoblocks.

One way could be to apply a GlobalBlock to the IP address used when a temp account is locked.

See also: T340275: Allow GlobalBlocking to block temporary accounts

In T355286#9467905, @Bugreporter wrote:

This may be a duplicate of T19929: CentralAuth account locks should trigger global autoblocks.

Thanks. We could keep them separate for now in case we go in a different direction or come up with additional measures for temporary accounts - but they may end up being duplicates if not.

I think we should generally get rid of global locking and extend GlobalBlocking to non-anonymous users instead (T17294: Allow blocking of global accounts). It's on my todo list to see if the WIP patch on that task can be fixed up with limited effort.

In T355286#9471508, @Tgr wrote:

I think we should generally get rid of global locking and extend GlobalBlocking to non-anonymous users instead (T17294: Allow blocking of global accounts). It's on my todo list to see if the WIP patch on that task can be fixed up with limited effort.

In standard practices perhaps, though locking is still relevant for scenarios such as account compromises, deceased users, etc.

+1 to Xaosflux. Global locks are a necessary tool, though global blocks should also be an option.

In T355286#9471514, @Xaosflux wrote:

In T355286#9471508, @Tgr wrote:

I think we should generally get rid of global locking and extend GlobalBlocking to non-anonymous users instead (T17294: Allow blocking of global accounts). It's on my todo list to see if the WIP patch on that task can be fixed up with limited effort.

In standard practices perhaps, though locking is still relevant for scenarios such as account compromises, deceased users, etc.

In this case Tgr propose to replace it with a variant of T222281: Add a way to prevent user from log in and disable a users session when blocking. Note if block-disable-login is available, in SUL wikis we need to prevent it be used locally, i.e. such option may only be enablable with a global block, not a local one, since it does not make sense if we lock out a user in wiki A but not wiki B.

In T355286#9471519, @Bugreporter wrote:

In T355286#9471514, @Xaosflux wrote:

In T355286#9471508, @Tgr wrote:

I think we should generally get rid of global locking and extend GlobalBlocking to non-anonymous users instead (T17294: Allow blocking of global accounts). It's on my todo list to see if the WIP patch on that task can be fixed up with limited effort.

In standard practices perhaps, though locking is still relevant for scenarios such as account compromises, deceased users, etc.

In this case Tgr propose to replace it with a variant of T222281: Add a way to prevent user from log in and disable a users session when blocking. Note if block-disable-login is available, in SUL wikis we need to prevent it be used locally, i.e. such option may only be enablable with a global block, not a local one, since it does not make sense if we lock out a user in wiki A but not wiki B.

From what I understand of that implementation, it would not work. One of the main reasons we (stewards) want global blocking is because it would optimally allow individual projects to unblock a user while preventing editing on all other projects, and would not log them out. A global lock is a different tool for a different purpose and should not be replaced.

Note only Tgr propose to replace global lock with a "disable session and disable login" option of global block. I do not oppose keeping global lock feature as-is.

People clearly want global locking to work like global blocking (e.g. T333244: Warn and confirm for self global locks, T19929: CentralAuth account locks should trigger global autoblocks). It doesn't make sense to maintain two parallel blocking infrastructures, especially when one of them doesn't integrate with MediaWiki's blocking system at all. Especially for something highly sensitive such as preventing account access (which the block system can also do, it's just not used on public Wikimedia wikis). The potential for conflict between local and global blocks was a problem, but the multiblocks migration resolves that, so we can just axe global locks and have GlobalBlocking (and normal blocking for non-SUL wikis, if there is any interest in that) take over the functionality.

Note: Since T17272/326e4d86c4d7, core MediaWiki (not just CentralAuth) has a user-is-locked concept, and is checked in BotPassword (T194605), though it seems no core MediaWiki feature is setting it.

In T355286#9471605, @Tgr wrote:

People clearly want global locking to work like global blocking (e.g. T333244: Warn and confirm for self global locks, T19929: CentralAuth account locks should trigger global autoblocks). It doesn't make sense to maintain two parallel blocking infrastructures, especially when one of them doesn't integrate with MediaWiki's blocking system at all. Especially for something highly sensitive such as preventing account access (which the block system can also do, it's just not used on public Wikimedia wikis). The potential for conflict between local and global blocks was a problem, but the multiblocks migration resolves that, so we can just axe global locks and have GlobalBlocking (and normal blocking for non-SUL wikis, if there is any interest in that) take over the functionality.

If it will be possible to configure a global block of an account to do exactly what a global lock does now, then I wouldn't have objections. It would need to log the user out on all projects, prevent log-in, and prevent local projects from unblocking the user.

For me, the main benefit of being able to globally block accounts is that individual projects can (I assume) unblock/exempt that user locally. The "lock" button in these future global block settings would also need to prevent that.

@Vermont I think that shouldn't be problematic. That said, being able to globally block registered users would be useful for the temporary account migration (because locks don't really work for temp users) and turning account locking into a block isn't directly relevant, so that's probably something for the longer term as preparing CentralAuth for temp users and for third-party cookie deprecation are much more urgent.

For now, do you agree T17294: Allow blocking of global accounts would cover this task (if it extends to temp users)?

Either T17294: Allow blocking of global accounts or T19929: CentralAuth account locks should trigger global autoblocks would be sufficient. Global blocks for accounts would be more useful in the long run though.

AHT is working on T17294: Allow blocking of global accounts so I think we can decline this (and T19929: CentralAuth account locks should trigger global autoblocks)?

In T355286#9556161, @Tgr wrote:

AHT is working on T17294: Allow blocking of global accounts so I think we can decline this (and T19929: CentralAuth account locks should trigger global autoblocks)?

(Just to clarify it's TSP which is Trust and Safety Product Team after the merger).

In T355286#9556161, @Tgr wrote:

AHT is working on T17294: Allow blocking of global accounts so I think we can decline this (and T19929: CentralAuth account locks should trigger global autoblocks)?

We should probably convert this task into allowing autoblocks for global blocks on accounts instead of declining, as T17294: Allow blocking of global accounts does not describe creating autoblocks for global blocks.

I hesitate support closing T19929: CentralAuth account locks should trigger global autoblocks because I wouldn't want to close that until global blocks can be made which have the same features as a lock (i.e. logging the user out immediately, preventing login, and not allowing local disabling). At that point I would be comfortable declining it as part of a broader moving locking to become global blocks effort.

Implementing the feature parity, especially logging out immediately and not allowing the user to log back in, isn't something that would be that would be useful for temporary accounts blocking (as you can't log into an existing temporary account as it has no password and logging the temporary account out when it is a major reason that global blocks are being used instead of locking for temporary accounts).

Disallowing local disables of the block may be something that is useful, but considering that the status quo for IPs is allowing individual projects to locally disable the blocks then I question how useful this would be for temporary accounts (considering that we treat them like IPs in some ways).