@Beetstra The ../ vector works on all websites, if I'm understanding T352827#9391030 correctly, while URL-parameter-based tricks like ?realPage=BadPage will depend on the website in question. The way it seems to me, someone whitelisting a page or path is expecting to whitelist just that page or path. But the use of \b—which makes sense on the blacklist, where we want to match the whole site—has the opposite effect on the whitelist. So most of these URLs should have been using $ to begin with.

That makes a lot of sense, @matmarex, thanks. What about the URL parameters angle, though? To give a real example that seems ripe for exploitation, on enwiki the neo-Nazi site Metapedia is blacklisted, but \ben\.metapedia\.org/wiki/Main_Page\b is whitelisted. That allows a link like https://en.metapedia.org/wiki/Main_Page?oldid=479369, which in fact would lead readers to Holocaust denial.

Oh, postscript to my original post: Is the \S in my proposed regex necessary, or does the extension implicitly stop looking for a match when it hits whitespace? If the latter, a simple . would work.

I want to be clear, I hesitate to even call this a bug or a misconfiguration on the extension's end; it's just counterintuitive behavior for end users. With https://badsite.com/page/../../badpage, for instance, the extension is correctly saying "This does match \bbadsite\.com\b, so it should normally be blocked, but it also matches \bbadsite\.com/page\b, so it should be let through". That's all valid parsing of the regexen. The problem lies in how URLs actually work (or, tend to work on most websites), which is beyond the purview of a simple regex-based extension. (If this were, say, a profanity-matching extension, it would be working perfectly.)

This is all great long-term planning (seriously!) but is there a chance of making a stopgap, light-weight solution for just EmergencyCaptcha? Even if it's as simple as, I don't know, a page editable only by stewards (a few ways to implement that) that allows for a comma-separated list of wikis to have EmergencyCaptcha on on; have a script check it every 5 minutes or something. (Probably not ideal implementation, but just giving an idea of a fairly cheap implementation.)

I think the issue is, unless I'm misunderstanding, the user only gets the toast message if they've already clicked the X. So someone who thinks the X is to remove their email will never get the message saying that it isn't. I think removing by default is a good thing to consider. I'd think basically all users in 2023 have an expectation that any website they verify their email with still knows that email, without needing a prominent reminder.

@KStoller-WMF Hmm my only concern there, if we're thinking about the lowest common denominator, is that some users might think that the "X" is to remove their email from the account. I think the solution works in principle, though.

In T333723#8749093, @Legoktm wrote:

Is there something I'm missing?

Anecdotal reports from several users of concurrent issues logging in.

Meanwhile over here:

• failed: https://en.wikipedia.org/wiki/Yaqoob_Salem_Yaqoob
• failed: https://en.wikipedia.org/wiki/Shelagh_Stephenson
• worked: https://en.wikipedia.org/wiki/Clyde_Nelson_Friz
• failed: https://en.wikipedia.org/wiki/Thespidium
• failed: https://en.wikipedia.org/wiki/New_Brunswick_dollar
• failed: https://en.wikipedia.org/wiki/Jean-Louis_Fousseret
• worked: https://en.wikipedia.org/wiki/Osusz
• worked: https://en.wikipedia.org/wiki/Castlelyons_GAA
• worked: https://en.wikipedia.org/wiki/Head_(surname)
• worked: https://en.wikipedia.org/wiki/Water_polo_at_the_2000_Summer_Olympics_%E2%80%93_Men%27s_tournament

Persisting here for a few days now (Chrome on ChromeOS). Going to boldly set this as "Unbreak Now!" since the extension is currently unusable for many/all people.

I think this is due to one of the three users I had in the query being a high-edit-count user (>300k). That would make sense if the DB is applying the limit only after running the whole query, which I gather is how it works? For the purposes of what I'm doing, I can just exclude users with >100k edits, and that ought to handle it. But there's some use cases at least where that wouldn't be an option.

Since there will be some cases where no relevant log entries exist either, e.g. https://en.wikipedia.org/wiki/Special:Contributions/2803:D100:E080:306:787A:3962:E1E7:52EB, would there be any way to work from deleted contribs, at least for admins? Otherwise we have a situation where an LTA could cause a lot of disruption on a deletion-eligible page that someone else created, that page gets deleted, and now there's no way to use IP Info on the IP the LTA was using, short of undeleting a revision, which is something of a perverse incentive.

@Aklapper Sorry, I thought these steps were clear enough. The reason I think this is a bug is a) that it is inconsistent behavior and b) that there is thus no obvious way to download a PDF of an old revision (if such a thing is possible).

• At https://en.wikipedia.org/wiki/Foobar, "Download as PDF" links to https://en.wikipedia.org/w/index.php?title=Special:DownloadAsPdf&page=Foobar&action=show-download-screen
• But at https://en.wikipedia.org/w/index.php?title=Foobar&oldid=1077185943 it links to https://en.wikipedia.org/w/index.php?title=Special:Book&bookcmd=render_article&arttitle=Foobar&returnto=Foobar&oldid=1077185943&writer=rl

("Printable version" works as expected in both cases.)

I happen to have force-created an account on testwiki a while ago for T302771, so I just tried blocking it there. An autoblock was made, but there's no block notice if I go to edit logged-out... I'm guessing the difference is my IP has probably changed since I force-created the account a month ago, and by blocking the "last IP address" used by the account I force-created, it's really just blocking whatever IP I had the day I created it?

My first thought was something about capturing groups, but it also fails on (?:x)*. I then played guess-and-check with quantifiers, and found that it works fine up till (x){0,2729}, but anything past that fails. Hmm.

See current behavior with int level values at this API result. Contrast with an apparent cached result that has str level values here (picking an arbitrary page unlikely to be edited anytime soon).

This should not have been rolled out without discussion of accessibility, especially since breaking up an HTML list is a classic a11y concern. It should be reverted until an accessible version can be rolled out, rather than left in production while a fix is worked on. I don't think we'd be okay with a comparably aggrevating change (based on what @Graham87 has said) staying in prod if it had comparably disruptive changes for non–screenreader users. If that accessible version can also not break list numbering (a tool I find invaluable in my workflow on-wiki... and yes, yes, https://xkcd.com/1172/, I know), that would be a great added benefit, but my primary concern is a11y.

I concur that this should be noted separately. It's an unusual circumstance that merits noting in the CentralAuth; it goes against the expectation that an account being attached on a wiki means that the user has visited it or interacted with it in some way; and, most of all, it's simply incorrect to say "created on login" for an account that, in the case of the example given above, I can tell you I have not logged in to since 2013.

@Daimona I found it in one other place. For whatever reason, there are a few blocks in Special:BlockList on enwiki logged against nonexistent users. (Not sure if that needs to be a bug of its own, or already is one.) This same thing happens there. See e.g. James5smith and SLR Consulting Ltd @ this BlockList query.

Ah. That's a shame. You'd think after two renames I'd know that. Oh well. If anyone does try to awaken a dormant account, they'll probably just think they forgot the password.

In T219279#7403097, @Pchelolo wrote:

with usertalk notes pointing them to Special:GlobalRenameRequest?

That's the issue, I can only leave a note on User_Talk:<capitalized username> (technical rename) page, not User_Talk:<unreachable_lowercase_username> since that user_talk will also be unreachable. And the capitalized version belongs to a different user. And without a notice if the owner of the account decides to come back, how would they know where to look for the note..

Was just about to ask this. While rare, there are cases of accounts making their first edits years after creation. Maybe systematically rename them to something like <capitalized username> (technical rename), with usertalk notes pointing them to Special:GlobalRenameRequest?

Thanks! :)

Idea: __PING__ and __NOPING__ magic words. Talk pages would be __PING__ by default. Content pages would be __NOPING__ by default. Wikis would typically add __NOPING__ to all archive templates. There could be safeguards against false positives, like "Ignore edits with multiple section headings" or "Ignore edits that start and end on different indentation levels." When an edit is ignored for one of these reasons, notify the user that no ping was sent (rather than the status quo, where you only get a "failed notification" message if the notification was sendable but not delivered.) That way false negatives aren't that big of a deal. And maybe have a way for users to intentionally disable pings for an edit, like by including "NOPING!" in their edit summary.

Since this is affecting the display of a large number of en.wp pages, I've boldly set it as high priority. My apologies if I shouldn't have.

@Dbrant Yep, it's working fine now. Thanks. Although I did get an error when I tried to edit a Lua module on the app. Just a generic "an error occurred," not the "page protected" message I was running into here. Is that a known bug(/feature?), or should I report it?