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?

I have not been following all of the details, but I do want to note that:

Re "is it a bug to allow partial blocks without specifying anything? if so maybe we need to disallow this entirely"

FWIW, there's lots of basically obsolete schemes that can show up in URLs (says the guy who actually ran a gopher server at one time). If somebody's going to work on this, I suggest pulling out an assortment of the examples from https://en.wikipedia.org/wiki/List_of_URI_schemes and writing a test to verify that at least the script won't barf on them.

Just adding my upvote to this. I'm looking at a case right now which is almost certainly somebody using a bot to commit high-speed vandalism via globally distributed IPs (presumably all proxies). They're all using the exact same highly specific UA string. The combination of an exact UA match and a fairly narrow time range (say, one hour) would be effective for this example.

Ah, I didn't even notice those were on two different sites. Bold I shall be!

Much appreciated, everybody. TWL is the best thing to come along in a long time, so thanks for taking the time to make it better.

OK, that does indeed get me where I want to go in fewer clicks, but it would still be good if the flow could be improved if you start from where I started. If nothing else, no login flow should include two consecutive pages with a "Login" button. And to address the "click randomly in the box" problem in step 3, there shouldn't be hidden buttons that you have to explore to discover.

It's just what I've got bookmarked. Should I be starting from a better place?

OK, that makes sense.

Just out of curiosity, what's wrong with setting up a syslog server and letting all the tools log to it?

In T379288#10323228, @EBernhardson wrote:

testing shows that to migrate from elasticsearch -> opensearch with security enabled you would need elastic to already be using tls for inter-node transport

Same here. I haven't seen any more problems since my last report on Nov 24.

If you guys think it's OK to make public, I have no objection.

Logged out again this morning on enwiki, commons, and wikidata. Approximately 1617 UTC. Clicking the login link got me to a "enter your username and password" screen, followed by a 2FA screen.

I just was away from my desktop for a few hours. When I came back, I was logged out on enwiki. There was a message in a box that said something like "You are logged in centrally, but you need to log in again". I know that's not the exact wording, but the message has gone away now. Meanwhile, I'm still logged in to commons, wikidata, and wikisource.

I love Bullseye, but I just don't see the point of continuing to maintain it when there's a WMF-supported service that basically does the same thing. If there's something Bullseye does that IPoid doesn't, then merge it into IPoid.

And again, logged out this morning. Approx 1549 UCT, first thing in the morning.

@Tgr any chance of a status update? I see you've been working on other phab tickets, so if you're busy, could you at least acknowledge that you've seen my pings here?

"I sometimes have Wikidata indicating that i'm logged out while saving edits, despite still being logged in."

1506 UTC, I just had it happen to me on the fly. I was logged in, went to respond to a comment using the "[reply]" link, and found myself logged out when I went to save my edit.

@Tgr could I (politely) bug you for a status update?

Could I get a status update on this? I sit on the Ombuds Commission. While we have not officially taken this up as a case, we have discussed it informally since it has the potential to lead to a user's IP address being leaked. The OC is charged with monitoring infringements of the WMF privacy policy and our purview includes being able to "suggest suitable changes to policies or software", hence our interest in this particular issue.

And 1513 UTC this morning.

1420 UTC this morning.

And again this morning. 1401 UTC is when I noticed it.

Just happened to me again. Approximately 14:24 UTC.

Just got logged out a moment ago (call it 27 October 1649 UTC) . I had been reading and editing normally for most of the day, and then when I clicked on a link I was suddenly no longer logged in. I'm not seeing anything of interest in my browser's javascript console.

@dcausse Yeah, that could certainly explain it. And, I do agree that in the scheme of things this seems like an obscure edge case and a rather low priority thing to invest effort to fix.

I hesitated to mention background color at all because I really didn't want to get into specific implementations. It was just one example of how this might be done, and probably a mistake that I went there at all.

In T377138#10227588, @Aklapper wrote:

Folks are free to edit Special:MyPage/common.css to display a different background color when logged in.

This just happened to me again, on my desktop. What makes this one different from others is that I saw it happen in real-time. In all the previous examples, I'd come back to my machine after not using it for a while and found I was logged out. In this case, I clicked on some link and was taken to

And this evening it happened to me on my phone, which had been logged in as [[User:RoySmith-Mobile]].

OK, thanks. I assume most of the spikiness in the green graph is just overall traffic volume varying over each 24 hour cycle?

So that implies that something (session handling? the more invisible autologin variants?) went wrong around August 8th

@Reader_of_Information I'm not sure what you're asking.

@Tgr thank you for the summary. Since I seem to be able to replicate this every few days, let me know if there's any data that would be useful for me to collect the next time it happens.

Just happened again.

@bd808 following up to our conversation earlier today, it turns out this ticket already exists (and I had forgotten about it). I'll just add, per our conversation, that I'd be happy to work with a WMF team to get this up and running, sharing what I learned from my own experiences, and then hand over long-term ownership to the WMF team. If you could socialize this in the right places, I'd appreciate it.

And again just now. Earlier today, I was using both my desktop and laptop on my home network. Right now, I'm on my laptop on a public WiFi connection and got logged out. This is just one day since the previous event.

And again this morning.

Happened to me again. The last time was 3 days ago.

Just happened to me again.

It just happened to me again. As for cookies, I've got:

Sounds good, thanks.

Before we make this go away completely, is there something that can be done to prevent this? I get that the browser is sending a false UA string, but how is it that we are able to deal with that on other actions and display the client hints instead of the false UA? Why can't we do that in this case?

Ugh. Yeah, I just manually logged out and when I logged back in again the arm Mini is sending:

When you say "could you check what the value of the User-Agent header is in the request?" I assume you're talking about when I login again? I'll try to grab that the next time this happens.

In T372702#10144557, @RoySmith wrote:

It just happened to me again. This time, I'm still logged in on my laptop, but logged out on my desktop.

I've also noticed recently that I've had to log in unexpectedly a few times. I happen to be a checkuser on enwiki, so I took advantage of that and ran a check on myself. Eliding the confidential data:

I recommend that between each request, the tool should wait as long as max lag which is between 0.1s to 0.5s in normal times. That would automatically makes it back off during stress.

It's certainly possible I saw it the first time on enwiki and the second time (a month later) on commons, but I can't be sure of that.

I opened this bug to record my observations with as much information as I was able to supply. Perhaps it'll happen to me again and I'll be able to add more details. Perhaps somebody else will read the report and say, "Yeah, that pattern is familiar, I think it's happened to me too". Such is the nature of intermittent problems.