Is there an estimate for when this fix will be deployed?

This makes sense based on what I've seen. This was originally observed on https://en.wikipedia.org/wiki/Chimpanzee which starts out with:

Cool. And I can verify that it's working. I just kicked off an IABot run and ran a self-check:

@Dreamy_Jazz Thanks for working on this (and to everybody else for comments that helped clarify the requirements) . Does "resolved" just mean the code is written, or is this actually deployed to production?

There's also a thread currently at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Loss_of_session_data which suggests this is a widespread problem.

I've been seeing this a lot on [[:en:Special:Checkuser]]. Chatting with some other CUs on Discord, I estimated I'm getting it on about 50% of the checks I run. Another CU estimated 25%. A Steward estimated they're seeing it on about 1/3 of the blocks they try to place.

Just want to mention that it would be nice if this happened. I could use this functionality for a project I'm working on and was surprised when I couldn't find this in the Action API. Eventually Claude mentioned this phab ticket, so here I am with a "Me too".

Done. My apologies for dragging my feet on this.

Thanks for the ping. I've been working my way through this slowly, but I'll get back to it.

Hmmm, weird, I tried it one more time and it worked this time, so I guess something intermittant.

Ah, I missed that above. Makes sense, thanks.

@MusikAnimal it's getting closer. In the same example I cited originally, hovering on the first word now highlights this:

At https://en.wikipedia.org/w/index.php?title=Poecilia_velifera&oldid=1359425527#Range, there's a set of {{maplink}}s which are encased in some complicated markup:

I suggest that instead of fixing this, support for these magic links be removed completely. This seems like basically an obsolete feature. Continuing to provide support for this adds complexity to the code base and, as this ticket demonstrates, increases the potential for future problems.

Oh, my. I had originally thought it was just the map on [[:en:Ceuta]] that was broken. It seems to be happening on all {{maplink}}s I can find.

It's been a few days, I'm afraid I don't remember any details beyond what I reported.

This was first noticed in https://en.wikipedia.org/w/index.php?title=Carlisle_%26_Finch&oldid=1366344752

Hmmm. I can not reproduce this right now, but from memory, what I did was went to lens.google.com and then in the box where it says "Past image link", I pasted something like:

My one concern here is that a common form of login failures is typing your username and password into the wrong boxes. If somebody did that, we'd end up logging their plain-text password.

Another example at https://en.wikipedia.org/wiki/Tribeca#/map/0, reproducible in an incognito window:

In T427158#11982234, @HakanIST wrote:

I scanned about 100k recent JPEG uploads on Commons for SOF9 markers and this is the only one.

The image is broken and can't be shown in browsers, there isn't much we can and should do

OK, I've given this some more thought and there is value in what Zzuuzz says about the security aspects of having this data in a file on a local disk. Still, the current method of copy-pasting the data from a browser has all those security disadvantages combined with being inconvenient. So, yeah, I'm might be coming around to being OK with Novem's suggestion of adding an API.

I get your point about not storing data locally, but right now, you need to do that anyway. Wouldn't it be better to at least make that convenient rather than copy-paste from the screen?

In retrospect, the data in /details is structured enough that JSON would probably make more sense than csv or tsv.

It starts with the copy-pasted data, but then it makes a bunch of API calls to retrieve additional information about individual users and IPs.

Yep, I'm talking about the checkuser stuff. Basically, all the data that's on the page:

This is a microcosm of a larger problem, which is that so much of how articles are formatted is cargo culting. What we're talking about here is essentially an API. VE exposes some functionality for managing references, so it needs a well-defined way for an editor to say "this is a reference", "this is where the list of references goes", etc. Then there's a fixed target that people can aim for. The folks who maintain VE. The folks who maintain the myriad of other reference-adjacent tools. The folks who write templates. And just plain editors who prefer to hand-edit wikitext. Then when something breaks, instead of finger-pointing about whether the problem is a VE update that was rolled a few days ago or a template change that was made back in December, everybody can point to the spec and say "This piece of the puzzle violates the spec: go fix that piece".

I don't think adding parsoid support will require the REST API, as it is also available via the action API. That's not to say supporting the REST API wouldn't be a good thing, just that it's not a blocker for this particular issue.

Just some random thoughts on other things that might be "sensitive transitions":

In T197160#4281158, @Bawolff wrote:

If we make too many things require reauth then we run the risk of annoying users. We also run the risk of making entering your password a common occurance which could aid phising attacks

I came here to open a similar ticket, but since this already exists, I'll just put my comments here.

My usual workflow is to click the IP link in Special:CheckUser when I want more info. As things stand now, when that fails with the dreaded "IP information for this address cannot be retrieved since no contributions have been made from it" message, then I need to manually flip over the Bullseye to get the information I seek, which is silly and inefficient.

I'll let the person involved identify themselves if they wish, but I just heard of another incident today where an enwiki functionary emailed emergency@ and got no response. Upon making a query through a back channel which would not be available to most users, it was confirmed that the mail was filtered as spam by gmail.

Interesting. Just for the sake of future phab archeologists, yeah, it turns out if I hit the WMF server directly from the command line, I get a nice, useful, error message:

According to this python-social-auth issue log, we apparently used to have a better (perfectly reasonable) 403 message:

Just for future reference, the fix ended up being to upgrade to social-auth-core 4.8.0 and set SOCIAL_AUTH_USER_AGENT in my django settings file.

You don't really want to advise bad actors how to get around the 403.

Is this the same project as https://github.com/magnusmanske/wikistream?

Ah, playing around a bit more (I just created [[User:Another Testing Account To Be Ignored]]), it looks like what I must have done was after creating the account I hit the back button in my browser and *then* typed WP:Sandbox into the search box.

In T411373#11419901, @Lucas_Werkmeister_WMDE wrote:

How exactly did you go back to [[WP:Sandbox]] (last step)? The URL shows you still on auth.wikimedia.org rather than en.wikipedia.org.

Oh, duh. My bad, I didn't notice that. Yes, that's all I was looking for.

+1 This seems like an obvious thing that should happen, and I assume trivial to implement.

Yeah, @Zzuuzz 's experience is the same as mine; the top and bottom controls have different behaviors.

I am strongly opposed to removing these entries from the db. The checks were requested, performed, and data returned to the requesting CU. The fact that the CU made a typo and asked for something other than what they intended doesn't change that.

OK, sounds good. I should have been smart enough to assume you guys knew what you were doing :-)

I'm all for computers doing things so humans don't have to, My only concern here is that (at least on enwiki) voter suffrage is determined by the community at an RFC. Implementing this automatic system would constrain the community to only using criteria which the software supports. If the community decided they only wanted editors whose usernames contained a Thorn to be eligible to vote, we'd be stuck. That is, of course, a silly example. But one could easily imagine less silly constraints which the community decides are important but happen not to be supported by this process. At the very least, we need to ensure we can revert to an enumerated list of eligible voters to accommodate such a situation.

OK, thanks. I agree it's a bug :-)

I'm not quite sure what you're saying. I understand your description of what's happening, but it sounds like you're also saying that's not a problem?

Yup, the deletions show in the preview screen:

Would it be possible to include a link to this phab ticket and/or the policy page in the HTTP error response?

Just acknowledging that I've seen my ping. I'll bring this to the attention of the commission, but can't commit to anything beyond that.

I totally agree that this is a poor design choice and should be fixed. Not just for the U/X issues Novem_Linguae points out, but also for technical reasons like GET vs POST informing caching decisions made up and down the HTTP chain.

In T398135#10956823, @SD0001 wrote:

Only polls that have ended can be archived.

What happens if you archive an election while it's still running?