In T359405#9736837, @kostajh wrote:

A few observations based on https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1008530 and https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1021768 in my local environment:

• For non JS and JS editing, the UI isn't updated when the user sees an error message that their edit didn't go through. This is probably OK.
• There are some instances where the user will see "centralauth-token-mismatch": "Sorry, we could not process your form submission due to a loss of session data.", error message in the UX. In some cases, they will be able to press "Save" after removing the text that trips the AbuseFilter or SpamBlacklist. In other case, the centralauth-token-mismatch error persists. It's hard to know if we'd see a similar issue in production CentralAuth setup
• Sometimes, the user will see the error about having their edit denied, then make a successful edit and see the temporary user banner, then on subsequent page load, the user is logged-out. This feels similar to T299193 but I am not sure. And I am also not sure if it has to do with my local setup or if we'd see something else in Wikimedia production.

It seems that once $wgAutoCreateTempUser['enabled'] = true; is set, it should stay that way, unless the wiki operator intends to permanently disable the feature. As that's out of scope for our purposes, I'm going to focus on a temporary switch off only.

A few observations based on https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1008530 and https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1021768 in my local environment:

In T356102#9735994, @achou wrote:

Thanks, that is what I am proposing as well. @achou, how feasible do you think this is from your side? It would involve accepting a POST with all the features (https://gitlab.wikimedia.org/repos/research/knowledge_integrity/-/blob/main/knowledge_integrity/featureset.py?ref_type=heads) needed.

@kostajh It would be feasible if clients providing the JSON data of the required properties to construct a Revision object. In Liftwing, we could bypass the preprocessing step that retrieves a revision from the MediaWiki API, and make a prediction directly.

Summary of meeting notes:

I see this error in my local environment (PHP 8.1, Apache) and am confused as to 1) why we don't see this error logged in production and 2) why this doesn't cause more serious issues related to central login, as the console error (Uncaught SyntaxError: Unexpected token '<' (at checkLoggedIn?type=script&wikiid=enwiki:2:223)) indicates that checkLoggedIn JavaScript doesn't run successfully.

In T360070#9707680, @sbassett wrote:

Hey @kostajh - Just wanted to check in and see if ext:IPReputation is ready for review or if you're planning any large, meaningful development cycles soon (and I should wait a bit). Thanks.

In T360870#9706355, @Urbanecm_WMF wrote:

In T360870#9705030, @kostajh wrote:

and we already have cases of actors existing without a user, so I don't think it is entirely a paradigm shift

For my own curiosity, I did a (poor) attempt on finding such actors:

mysql:research@dbstore1007.eqiad.wmnet [cswiki]> select * from actor where actor_user is null and actor_name not like "%:%" and actor_name not like "%.%" and actor_name not like "%>%" limit 100;                                                
+----------+------------+------------------------------------------+
| actor_id | actor_user | actor_name                               |
+----------+------------+------------------------------------------+
|   463290 |       NULL | Template namespace initialisation script |
|   797707 |       NULL |                                          |
|   832583 |       NULL | Conversion script                        |
|  1298157 |       NULL | Unknown user                             |
+----------+------------+------------------------------------------+
4 rows in set (1.989 sec)

mysql:research@dbstore1007.eqiad.wmnet [cswiki]>

The is not like conditions in the SQL correspond to IP actors (IPv6 and IPv4 and imported users (> is used for separating the interwiki prefix for remote users).

Unless the conditions filter out other cases, this means the only actors without an user are IP actors, imported users and historical system users. Out of those, only IP actors represent human actions (imported users represent an artificially inserted action into the wiki's past, while maintenance users represent a system-taken action).

In T360870#9705113, @Urbanecm_WMF wrote:

In T360870#9705030, @kostajh wrote:

Likely, there are also other tools that would break with the introduction of the new type of actor. Such breakage might be often non-apparent (unless one's testing against a particular workflow or is systematically going through all usages). We would likely need to conduct a full audit of all the codebases, to ensure each works fine with partial temporary actors (similar to what we did/are doing with temporary accounts themselves). This seems like a lot of work.

I am not sure about that. It seems like the use case here is pretty well contained, and we already have cases of actors existing without a user, so I don't think it is entirely a paradigm shift. I do agree that if we had to do a full audit of actor/user handling code and tooling, this approach would be more trouble than it is worth.

Maybe I am missing some, but AFAIK, the only no-user actor which can trigger logged actions is an IP actor (which we're moving away from). There are special-purpose actors for imported revisions, which are fairly rare and they also do not make sense in most contexts (such as in Special:CheckUser or Special:Log), while the newly-proposed actor type would need to be supported there.

In T360870#9683832, @Dreamy_Jazz wrote:

In T360870#9682076, @Urbanecm_WMF wrote:

In CheckUser's case, the row would get displayed, but only when querying via IP. However, the displaying would not show the "unsaved" remark we can see in Special:AbuseLog (because of missing handling in CheckUser itself, I presume).

IMPORTANT: Unfortunately, semgrep supply chain found a vulnerable dependency that is reachable within ext:ReportIncident's dev dependencies (see: P58901). This is a dependency for @babel/preset-env@7.16.11 and jest@27.4.7, so perhaps merely bumping those versions to newer releases would mitigate the issue. Given vulnerability is for code execution, it would still be fairly sensitive even within a "dev" context.

In T326873#9663749, @JWheeler-WMF wrote:

@Niharika can you help our team understand the priority and urgency of completing this ticket?

btw, in case this is relevant, https://logstash.wikimedia.org/goto/b060c8f0c137245fc0d63b9329583abe shows a spike of a bunch of requests with the same request ID, but those logs for handling web requests. I can file a separate task for that if you think it's worth investigating further.

yeah I think this was a duplicate of T76245, although, this task had proposed to use Quibble for the heavy lifting instead of having another set of developer environment tools for things like cloning, installing, and serving MW.

Here is a demo of this stack of patches.

In T360870#9658553, @Tchanders wrote:

The block link in the log entry takes you to Special:Block in an error state, since the user doesn't exist, so we'd need to remove that.

In T360595#9648505, @hashar wrote:

an instance that has been phased out more than two years ago by T2830123

Just linking T283013: Migrate beta cluster to ELK7 here, per the above.

In T334623#9656873, @Tchanders wrote:

In T334623#9656689, @kostajh wrote:

OK, option 1 would indeed not work for SpamBlacklist because it uses a regular ManualLogEntry which needs an actor.

One idea I've explored is to allow ActorStore to not require a user ID in validateActorForInsertion() when working with a temp account:

@@ -628,7 +628,8 @@ class ActorStore implements UserIdentityLookup, ActorNormalization {
 		}
 
 		$userId = $user->getId( $this->wikiId ) ?: null;
-		if ( $userId === null && $this->userNameUtils->isUsable( $user->getName() ) ) {
+		if ( $userId === null && $this->userNameUtils->isUsable( $user->getName() )
+			&& !$this->userNameUtils->isTemp( $user->getName() ) ) {
 			throw new CannotCreateActorException(
 				'Cannot create an actor for a usable name that is not an existing user: ' .
 				"user_name=\"{$user->getName()}\""

That allows temp account names to appear in Special:Log in a similar way to how they appear in AbuseFilter log -- they are visible, clickable names, but when you visit the username, you'll see a message that it doesn't exist. There's a further complication in that if the user goes to save a successful edit, CentralAuth / AuthManager don't know how to handle a row in the actor table that has an actor_id and a actor_name but actor_user is null (because the user account didn't exist when we created the actor table row). So we'd need to work out a safe way to update the actor table entry to have the newly created user ID as part of temp account creation.

I think conceptually it's correct that the performer of these actions is an actor (an individual who did something), but not a user (no need to be logged in). This either means we have a new type of actor here (which is similar to an IP actor or a system actor in that it has only an actor row), or we need to re-define temp users as not necessarily having a user row. Since we don't currently have any user types that may or may not have a user row, the second idea might be a bit tricky.

The idea of being able to link the log to a temp account if a successful edit is made later is nice. If it's not possible, I think we can still use this idea.

Since this conversation is going a bit beyond how to solve for AbuseFilter, I've made a new task: T360870: How should we represent actors that do something loggable but don't create a temp account? and discussed this idea a bit there.

In T334623#9653885, @kostajh wrote:

In T334623#9649067, @kostajh wrote:

In T334623#9587082, @STran wrote:

I did some additional research while reviewing T358632: CannotCreateActorException when creating a temporary account on an edit which causes an abuse filter log which resolved the issue of the actor not existing and throwing an error whenever an anonymous user attempted an edit that triggered a filter. Once that error was fixed, the current situation actually seems less breaking than expected:

• An anonymous user, upon making an edit that flags a filter, will be logged as a temporary user but no temporary account will have been made eg:

• An anonymous user makes an edit that is logged but not disallowed will have a temporary account created for them. If the event is logged (eg flagged), at the time of the log, the account does not exist. Attempts to show the IP via IPInfo's "Show IP" button will fail (because there is no edit to look up). However, AbuseFilter log will have still logged the IP and this IP goes away when the abuse_filter_log table clears its older IPs.
• If a still-anonymous user proceeds to make a valid edit, the account is then created using the username associated with the failed action.
• If a different anonymous user makes an edit, failed or otherwise, they will receive the next available username (so users aren't wrongly associated with another user's actions).

This isn't the worst situation to be in, but it does create this oddity where the username for a temporary account exists but no real account exists. Maybe this is okay? If the user never makes a valid edit with that account (afaik as long as they have the cookie they have the username and if the cookie goes away then so does that account name) then it doesn't necessarily matter if an account under that name ever exists. It's just a weird precedent.

In this scenario, we would probably still have to fix the broken "Show IP" button.

After working on T359405: Create temporary account early in edit cycle for all edit attempts (see T359405#9649058), I'm wondering if the existing behavior @STran describes above isn't the best approach after all.

The only thing we might want to do there is add a "Show IP" button that works here. But otherwise, there'd be nothing more to do, AFAICT.

So, summarizing the options, as I see them:

1. Do nothing

• Let AbuseFilter continue to log the reserved username.
  • If the user makes a successful edit, they will be associated with their previous AbuseFilter-logged events
  • Optional: Add a "Show IP" button on Special:Contributions or in AbuseFilter log for temp account names that appear in the log but don't exist as accounts

Advantages:

• Limited additional work ("Show IP" button). The IP reveal functionality might also be unnecessary in this context for abuse mitigation workflows.

Disadvantages:

• Need to educate AbuseFilter reviewers as to why temp account names exist in logs without actual existing accounts
• Won't work for other extensions that need to log an actual existing user as part of edit denial workflows

2. Create account at beginning of internalAttemptSave and don't worry about detached user accounts

• Create account at beginning of internalAttemptSave, before any hooks/constraints

Advantages:

• Creates a user for an edit attempt which allows for easier logging constraint checks

Disadvantages:

• Something on the order of 55k accounts created per month, of which some percentage won't be used at all
• Poor UX for users who failed to edit (but are actually logged-in). They'll see some form of CentralAuth / session errors, unless we implement some fix around it. They'll also not be able to visibly see that they're logged in on receiving an error (unless we do something about that too)
• Inability for these users to be seen as the same user when visiting other wikis

3. Create account at beginning of internalAttemptSave and find way to perform top-level login on failure

• Create account at beginning of internalAttemptSave, before any hooks/constraints
• Perform a top-level login on failed edits

Advantages:

• Same as 2, but we also ensure the user is attached to loginwiki, and that there is an improved UX in failure modes

Disadvantages:

• Something on the order of 55k accounts created per month, of which some percentage won't be used at all
• Wikitext editors lose their changes on failed attempts (due to top level redirect)
• Modifying EditPage.php to support parsing error messages into query params for top-level login will be painful and clunky. Same goes for API driven editing.
• Would need to modify wikitext editor UX and API driven editing (VisualEditor/DiscussionTools/Wikibase) UX to support the top-level redirect workflows on edit failures

---

It may be the case in the future that CentralAuth's SSO changes (T345249, T348388), in which case option 3 becomes more palatable, and would require less refactoring.

It seems like the least disruptive option here is option 1 (status quo; only create temp users on success, and hooks that fire before success should make use of the reserved temp user name, but not a full account), assuming that it would work for SpamBlacklist (T358806).

In T334623#9649067, @kostajh wrote:

In T334623#9587082, @STran wrote:

I did some additional research while reviewing T358632: CannotCreateActorException when creating a temporary account on an edit which causes an abuse filter log which resolved the issue of the actor not existing and throwing an error whenever an anonymous user attempted an edit that triggered a filter. Once that error was fixed, the current situation actually seems less breaking than expected:

• An anonymous user, upon making an edit that flags a filter, will be logged as a temporary user but no temporary account will have been made eg:

• An anonymous user makes an edit that is logged but not disallowed will have a temporary account created for them. If the event is logged (eg flagged), at the time of the log, the account does not exist. Attempts to show the IP via IPInfo's "Show IP" button will fail (because there is no edit to look up). However, AbuseFilter log will have still logged the IP and this IP goes away when the abuse_filter_log table clears its older IPs.
• If a still-anonymous user proceeds to make a valid edit, the account is then created using the username associated with the failed action.
• If a different anonymous user makes an edit, failed or otherwise, they will receive the next available username (so users aren't wrongly associated with another user's actions).

This isn't the worst situation to be in, but it does create this oddity where the username for a temporary account exists but no real account exists. Maybe this is okay? If the user never makes a valid edit with that account (afaik as long as they have the cookie they have the username and if the cookie goes away then so does that account name) then it doesn't necessarily matter if an account under that name ever exists. It's just a weird precedent.

In this scenario, we would probably still have to fix the broken "Show IP" button.

After working on T359405: Create temporary account early in edit cycle for all edit attempts (see T359405#9649058), I'm wondering if the existing behavior @STran describes above isn't the best approach after all.

The only thing we might want to do there is add a "Show IP" button that works here. But otherwise, there'd be nothing more to do, AFAICT.

In T334623#9587082, @STran wrote:

I did some additional research while reviewing T358632: CannotCreateActorException when creating a temporary account on an edit which causes an abuse filter log which resolved the issue of the actor not existing and throwing an error whenever an anonymous user attempted an edit that triggered a filter. Once that error was fixed, the current situation actually seems less breaking than expected:

• An anonymous user, upon making an edit that flags a filter, will be logged as a temporary user but no temporary account will have been made eg:

• An anonymous user makes an edit that is logged but not disallowed will have a temporary account created for them. If the event is logged (eg flagged), at the time of the log, the account does not exist. Attempts to show the IP via IPInfo's "Show IP" button will fail (because there is no edit to look up). However, AbuseFilter log will have still logged the IP and this IP goes away when the abuse_filter_log table clears its older IPs.
• If a still-anonymous user proceeds to make a valid edit, the account is then created using the username associated with the failed action.
• If a different anonymous user makes an edit, failed or otherwise, they will receive the next available username (so users aren't wrongly associated with another user's actions).

This isn't the worst situation to be in, but it does create this oddity where the username for a temporary account exists but no real account exists. Maybe this is okay? If the user never makes a valid edit with that account (afaik as long as they have the cookie they have the username and if the cookie goes away then so does that account name) then it doesn't necessarily matter if an account under that name ever exists. It's just a weird precedent.

In this scenario, we would probably still have to fix the broken "Show IP" button.

I spent some time on handling top-level redirects for temp accounts on failed edits. My main observations are:

In T284047#9643460, @FJoseph-WMF wrote:

@kostajh is this still relevant or can this ticket be closed out?

In T326929#9634196, @ifried wrote:

Thanks for your feedback, @kostajh! Would @Tchanders be responsible for making the final decision?

It would be nice to make this a little more complicated and include CentralAuth in whatever documentation/tooling we create, because that is a pretty common use case for setting up a multi-wiki setup in a local development environment.

In T360145#9636661, @kostajh wrote:

According to iPoid-Service, at least some IPs on this range are associated with Luminati Proxy. So there is some amount of increased risk associated with relaxing rules for this range.

I would like to require a temporary lift of IP cap for the following IP address : 206.167.136.0/24. This IP address has been blocked since yesterday as the students were attempting to create their Wikipedia accounts in class, prior to next week's event.

Here's a link to the existing block on anonymous editing from this range for reference. It looks like that block (no editing for anonymous users) dates from 2022.

@Synchroniseuse is it possible that the students create their accounts from home or via mobile devices? That should then allow them, as logged-in users, to edit from 206.167.136.0/24 with the current block settings.

According to iPoid-Service, at least some IPs on this range are associated with Luminati Proxy. So there is some amount of increased risk associated with relaxing rules for this range.

Stalled pending the creation of the schema and MW implementation in T354597: Record IP reputation data for account creations and edits.

Can we update documentation to instruct users to run rebuildLocalisationCache.php (or update.php with some custom flag to clear the localisation cache) after adding wfLoadExtension() in LocalSettings.php? I think it's pretty common for extension registration in other platforms to require an additional command to properly register an extension, and it doesn't seem that onerous.

We discussed in temp accounts weekly check-in today. What we'll do for now: remove wikis with legacy Vector from the pilot wikis. Ideally, by the time we are rolling forward to other wikis, we'll be farther along with deploying Vector 2022 to wikis still using legacy Vector. If not, we can revisit this task.

Adding Quality-and-Test-Engineering-Team as well, cc @Jrbranaa

In T357777#9622856, @dom_walden wrote:

@kostajh Should this task still be in review? I see one open patch.

In T332022#9622616, @thiemowmde wrote:

Can I somehow help pushing this forward? The Flow boards on wikis like mediawiki.org are currently heavily hit by spam bots. This is especially frustrating when the bots do exclusive Flow actions like editing the same topic summary over and over again. While this can be undone it's clumsy and frustrating as it is – by the nature of the separated Flow databases – not fully integrated into the normal MediaWiki workflows. And then there is this: T309941: IPInfo refuses to show IP informations if IP made only Flow modifications.

I'm planning to create a schema like "ip_reputation_log", looking something like:

In T356492#9620658, @Dreamy_Jazz wrote:

@kostajh has this change been deployed yet?

@Urbanecm_WMF and I discussed this one a bit today.

This time there was no issue:

In T334623#9615890, @Daimona wrote:

In T334623#9615760, @kostajh wrote:

@Daimona @Dreamy_Jazz do you have in mind which constraints are user-independent and which are user-dependent?

If we introduce that distinction, we might start by considering every existing constraint as user-dependent, as that should preserve the existing behaviour. Then, for simple constraints it should be just a matter of auditing their implementation to see if they need a user or not. To prevent the context user from being accessed deep down in the call stack, we might explore emitting a warning if something calls RequestContext::getMain()->getUser(). I don't know if that'd work though; otherwise, it would help us validate that a given constraint is (or isn't) user-dependent.

In T359653#9615869, @Bugreporter wrote:

Another idea is expire temporary account that is inactive for some shorter time (e.g. 7 days or 30 days). But we need some way to store how temporary account is recently used (maybe just store it in cache?)

In T339377#9612243, @Jdlrobson wrote:

We can repurpose this for legacy Vector, but just to set expectations - this is likely going to require a new design for the banner or a big architectural change to Vector. I would prefer the former if possible!

I've marked as UBN as it seems like this might cause problems in deployment, and I canceled the UTC morning backport as a result. Please lower the priority if I've misunderstood.