Not sure if there’s a good Phabricator tag for assertCurrentUser() (the Gerrit change adding it had no attached task, and T217774 was a Flow-specific issue), but CC @Tgr and @kostajh from there.

IMHO there’s no reason to assert that the user is anonymous – if the user logged in in another tab, that doesn’t leak information in the same way that logging out does. We could add a second parameter to assertCurrentUser() to control whether it asserts only logged in or all session states (boolean onlyAssertIfLoggedIn?), but given that it’s not used that frequently yet (codesearch), maybe we can get away with just changing its default behavior.

Alternative idea: add a value like assert=!user to the parameter (by analogy with rcshow’s anon/!anon – I thought we had !user somewhere in the API too but apparently I misremembered that) which would allow either IPs or temporary accounts, and make assertCurrentUser() emit that.

Change #1196402 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/core@master] mw.Api.assertCurrentUser: Don’t add assert=anon

https://gerrit.wikimedia.org/r/1196402

Note, since I was wondering: once you have a temporary account and reload the page, assertCurrentUser() does work correctly. It sends a request like assert=user + assertuser=~2025-30, and apparently the API accepts that (i.e. assert=user seems to correspond to User::isRegistered(), not User::isNamed()).

In T407337#11276036, @Lucas_Werkmeister_WMDE wrote:

(i.e. assert=user seems to correspond to User::isRegistered(), not User::isNamed()).

(Which suggests that my assert=!user idea above isn’t so great, because that would imply that temporary accounts fulfill both assert=user and assert=!user, which is nonsense. I guess it could be assert=!named instead, if we want to go with that approach.)

assertCurrentUser() tries to prevent you from making an edit under a different username than what the UI implies. If the UI says the edit will be anonymous but then it goes under some logged-in username, that's still not great.

One option would be to make assertCurrentUser() not differentiate between anon and temp users (!named as you suggest). When temp users are enabled, the UI will always tell the user a temp account will be created so that can't be very misleading.

Another option would be to assert the "potential current user", which would be a temp user during an editing workflow - EditPage::getUserForPreview() has the concept of a "placeholder temp user" to be shown for edit preview, maybe that could be exposed somehow. Seems really messy though.

The third option would be to update the state assertCurrentUser() asserts against. @matmarex worked on updating some JS variables in-place after login, maybe such a capability would be useful here.