I've used the token method (but feel free to change it if the log method makes more sense!)

In T239680#5717411, @AronManning wrote:

To authorize a subsequent request (sorting/paging), checking the existence of a CU log entry (with the CU user, check timestamp, target users) should be necessary and sufficient.

It looks like other extensions use that library and sign the JWT with the $wgSecretKey so I think that should be fine.

In T239680#5713457, @Mooeypoo wrote:

I am wondering if it won't be even more straight forward to "just" send all the data directly from the form each time we paginate. We can set up a hidden field or POST param noting whether logging is required based on the UI action...

In T239682#5709079, @dom_walden wrote:

I guess this is fine. I don't really know...

In T238714#5698452, @dmaza wrote:

Where do unregistered edits on that IP fall? is that part of the 10 edits from 3 other users or do we want to exclude those?

In T239451#5705017, @Anomie wrote:

But would making intestactions=full be subject to replica lag harm the use cases it's meant to support?

Looking at the mocks: https://prtksxna.github.io/wmf-cu-prototype/

In T175587#5685276, @Niharika wrote:

Gotcha. Good to know.
Rhetorical question: Why couldn't they have simplified this by making the UA simply be a concatenation of the three parts. 🤔

In T175587#5681956, @Niharika wrote:

For each UA we have the three parts. For 22 records, that is 66 pieces. So for each library, how many of those were right/wrong would be helpful to know.

In T175587#5681931, @Niharika wrote:

It would be helpful to quantify how often we got accurate results from both the libraries.

In T238827#5681783, @Tchanders wrote:

@dbarratt 1-5 are already done in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/CheckUser/+/552269/

It seems like we should:

1. extend TablePager
2. implement getQueryInfo() (to specify the initial query)
3. implement preprocessResults() (to attach the additional data to each row)
4. implement getFieldNames() (to ensure the field names are what we want to display)

I retrieved 20 random User Agent strings from the cu_changes table on eswiki and put them into a spreadsheet and compared the parsing of devicedetector.net and whichbrowser.net.

In T175587#5676994, @Niharika wrote:

I see. I think we need some baseline estimate of how often it is wrong. If it's like 1 in 10 cases, then maybe we could split up the UA and give them a disclaimer that it might be wrong and give them an option to see the complete UA. If it's 1 in 2 cases, we probably don't want to do the splitting.

or rather, the problem does not exist on he, it only exists on en.

In T200938#5676986, @Niharika wrote:

@dbarratt Has this been deployed already? In that case we can verify if the problem exists on the actual hewiki.

In T175587#5676953, @Niharika wrote:

Hmm, if we can have a sense of how inaccurate a parsed UA is (say, 80% or 20%) then based on that we can decide whether to display the complete UA or not. One of the use cases of this is to also know when the user might have spoofed their UA.

In T238603#5674993, @Prtksxna wrote:

Since the user/ip input is complex, and not something we have elsewhere in our system, I am inclined to give the user a bit more guidance here. It is a bit odd that an input could accept both usernames and IPs and I am expecting that there might be some confusion around this. I suggest we keep this for now and take another look at it after some usability testing.

I've created T238603: Placeholder text on Special:Investigate seems unnecessary as a follow up to my concern in T237034#5672654

In T237034#5672672, @Tchanders wrote:

@dbarratt See screenshots in T237034#5661181 and @Prtksxna's reply in T237034#5670732 - we've removed the help text for the User and Reason widgets to make it less busy, and made the placeholder text more informative instead

@Prtksxna This seems really busy to me...

In T237034#5670732, @Prtksxna wrote:

How about UserName? Or would that be too generic? Thoughts @Tchanders @Niharika?

This is driving me bonkers... for me it seems to happen on Firefox, but not Chrome

I ran this query on eswiki:

SELECT
  TO_SECONDS(MAX(cul_timestamp)) - TO_SECONDS(MIN(cul_timestamp)) AS duration
FROM cu_log
WHERE STR_TO_DATE(cul_timestamp, '%Y%m%d%H%i%S') > DATE_SUB(NOW(), INTERVAL 1 YEAR)
GROUP BY cul_user, cul_reason
HAVING COUNT(cul_id) > 1
ORDER BY cul_timestamp

I could create a graph as you suggested earlier, that might reveal more insights.

In T234557#5666085, @aezell wrote:

I think we can take a closer look at the actual data in these rows and see if there's another way to slice it to identify some patterns.

In T235047#5665150, @dmaza wrote:

I believe it is because the headers are not being set on the request due to what I explained in my last comment

In T238240#5664155, @dom_walden wrote:

I don't see anything currently that uses HTMLUsersMultiselectField at the moment.

Re-opening to give opportunity for QA.

In T237852#5662309, @tstarling wrote:

That's why I said "basically". The fact that access tokens are sufficient for authorization was not relevant to my point, which was that OAuth 2.0 is not significantly more difficult for clients to implement than traditional CSRF tokens.