User Details
- User Since
- Sep 21 2017, 11:21 PM (323 w, 4 d)
- Availability
- Available
- LDAP User
- RoySmith
- MediaWiki User
- RoySmith [ Global Accounts ]
Sun, Dec 3
Fri, Dec 1
Wed, Nov 29
Nov 2 2023
I've pinged the developers at [[:en:Wikipedia talk:HotCat ]]
Nov 1 2023
@Jdforrester-WMF why is this HotCat's fault? From the description above, it sounds like the value of wgCurRevisionId being returned is incorrect. Surely a tool like HotCat should be able to rely on that being set properly, no?
Oct 31 2023
Oct 25 2023
@Harej, I disagree with prioritizing this as "medium". This involves silent data loss. That should never be a medium priority. It also sounds like the fix has already been identified (use baserevid instead of basetimestamp) and that fix is probably trivial to implement. So why toss it on the medium heap, which basically means it'll never get fixed?
Oct 19 2023
Oct 15 2023
Wow, yeah, that fixed it, thanks.
@Snaevar I'm reopening this. If after some discussion by all the interested parties it is decided not to implement this feature, that's one thing. I know you disagree with my assessment, and I welcome your input, but I don't think it was appropriate for you to unilaterally close the ticket without discussion.
Interesting. I can still reproduce it here. I normally use Chrome, but just tried this in Firefox 109.0.1 (64-bit) and can reproduce it there as well. I'm not seeing anything exciting in the console:
Oct 14 2023
This feels like it's related to T332799
Oct 13 2023
Oct 12 2023
Oct 9 2023
This is related to T346835
@kostajh I'm not sure what I could usefully share that wouldn't violate CU confidentiality. I also don't think it would be germaine to this ticket. I see two distinct issues here:
Oct 8 2023
Just wondering if anything is happening to this? I'm working another LTA case right now. We list over 400 confirmed socks spanning 2 years. I suspect there's many more that we either haven't found or haven't bothered to tag. This particular LTA has a pattern of creating a new account on some random IPv4 address then switching to a v6 mobile network for editing. If we could block the v6 /36 only for anon or unconfirmed users that would put a big dent in their operation, or at least make it more work for them to roll out new socks. Such a block would have almost no collateral effect. I don't want to fully block the /36 because it would have way too much collateral damage.
Sep 19 2023
The sandbox idea works for me, thanks.
Sep 18 2023
I just got another one of these:
Looking at the suggested workaround instructions:
Sep 10 2023
Aug 10 2023
Jul 9 2023
Jul 4 2023
Jul 1 2023
When I do this:
Jun 28 2023
Thanks for the link. I remember reading that page at some point a long time ago, but didn't remember the details.
Jun 27 2023
Is this documented anywhere?
Jun 26 2023
Jun 10 2023
In case people are not aware of the practical issue here, I'm now getting a:
Jun 9 2023
I agree that this is a bug. I just got bit by the same problem. See https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Autosubscribed_to_a_bunch_of_identical_threads_by_mistake?
Jun 6 2023
I would not be surprised if the checkuser extension were sensitive to a similar DOS attack. If not in the PHP backend itself, then likely in the javascript which builds the summary table.
Jun 5 2023
Jun 2 2023
May 30 2023
May 28 2023
May 17 2023
There is one case that I know of where a user with enough edits to be ready for consideration for admin rights on the English Wikipedia was determined to be a sockpuppet.
Do we need to store (as opposed to request) client hints for all of the CheckUser-loggable actions, or is there a subset that are most commonly linked to the type of abuse that we use this information for?
May 14 2023
OK, I mostly understand what's happening here. My user-config.py defines oauth credentials for {en,test}.wikipedia.org, and those credentials were created to only be valid on those specific projects. test_create_short_link() forces a login to meta, and that's one of the ways this fails.
May 13 2023
On the other hand, maybe this is a server-side issue? I'm all the way down to
It's possible this is a bug in the upstream requests library. I can reproduce this (on both MacOS and Debian) with:
I think you've got that backwards, the flag is not set, so it defaults to '0', which is != '1', so the assertion is run. Which leads to a couple of additional observations:
May 12 2023
I see what's going on. This is somehow related to authentication. I have OAUTH credentials in my user-config.py file. It's unclear why it should cause this behavior, but if I comment out the:
May 1 2023
I'll echo the sentiments of my fellow CUs. There are a number of LTA cases I track where the abuser uses a model of phone that we don't see very often, so the UA is the definitive way to track the person. Tracking by UA is especially important in parts of the world where:
Apr 22 2023
Oh, I'm guessing this is due to T334940
Mar 28 2023
As noted by others, I agree that it's too domain-specific to be part of the Page class.
Mar 25 2023
FWIW, I can reproduce this as well.
Mar 22 2023
Go to https://en.wikipedia.org/w/index.php?title=Fleetwood_Park_Racetrack&oldid=1146074624. Scroll down to the "Miscellaneous" section and look at the reference after "...toboggan slides, illumination, and music". It is ' "Sport at Fleetwood Park". The New York Times...', numbered 38
The wikitext for that citation reads:Mar 19 2023
Mar 15 2023
My first thought was that sitemaps made sense back in the days when dinosaurs roamed the internet. Then I looked at https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview to refresh my memory of why they exist. The main purpose is to enable web crawlers to find pages which aren't reachable by following the link tree from your main page.
Mar 14 2023
How would you feel about having site_detect.py:check_response() raise ServerError if response.status_code == 403?
Interesting. It seems to be platform dependent.
Mar 12 2023
Oh, I see how this works. WikiHTMLPageParser overrides handle_starttag() which calls set_api_url().
I don't understand why this failure is specific to github. It's failing for me as well on my MacOS laptop.
Mar 8 2023
You posted two screenshots (IMG_7394.PNG and IMG_7395.PNG). How did you generate those, i.e. what do I have to do to view those two different versions of the page on my phone?
Could you post the URLs used to generate those? I tried scaling them to phone-size on my desktop, that's not a good comparison because the desktop's monitor doesn't have anywhere near the resolution my phone has.
Mar 7 2023
Sorry, this is a duplicate of T331486
Mar 1 2023
Hi. Sorry it took so long to get back to you. On https://en.wikipedia.org/wiki/Wikipedia_talk:Did_you_know, on the page I've got:
Feb 28 2023
Feb 26 2023
The example I gave in T329063 is now working better.
I assume this is due to the workaround mentioned by TheDJ on Jan 19 2023, 3:13 AM, so that looks good. Thanks.Feb 18 2023
@TheDJ before I do that, is there any value to the people trying to debug this to my leaving things they way they are now, since it seems I can reproduce it and nobody else can?
I'm seeing this again. I again have in my console:
Feb 16 2023
I just saw it happen again on https://en.wikipedia.org/wiki/Wikipedia_talk:Did_you_know#Prep_7:_Chicago_station_(CTA_Logan_Square_branch)_(nom)
Feb 15 2023
This reminds me of T326996.
The particular thing I wanted to do today is move a python wheel file which I had built on my local dev machine and wanted to install on toolforge. Checking the wheel into git would make no sense. The way I currently install my app is indeed to push the source to git and pull that down into toolforge, but I'm exploring if doing wheel installs would be simpler.
I'll add one more comment. Sometimes I've copied what I need over to /tmp because it's world writeable and worked with it there. From any rational security analysis, that's the wrong thing to do, but sometimes you need to get something done and you find a way to do it. If you make it easy for people to do the right thing, they'll do it. If you make it difficult for people to do the right thing, they'll do the wrong thing if that's what lets them get their work done.
Just noting that I've run into exactly this same issue (see this thread). So I'll add my voice to supporting getting this implemented.
Feb 13 2023
I haven't seen it again after I reported the original incident. But I'll let you know if I see it again.
Feb 12 2023
FWIW, I described another way to reproduce this on enwiki vpt
Feb 9 2023
Interesting. Yes, I'm seeing javascript errors on page loads (even before I try to edit anything). It's not entirely reproducible, but they're all variations on:
Feb 7 2023
I can even replicate it on my desktop, using Chrome's mobile device emulation. For example, looking at https://en.wikipedia.org/w/index.php?title=User:RoySmith/sandbox&oldid=1138008943&useskin=vector2022, emulating a Galaxy Fold at 280 x 653 pixels. This one is using my normal (User:RoySmith) account, MacOS 12.6.1 Chrome Version 109.0.5414.119 (Official Build) (x86_64)
On the phone, it's my mobile account, which is totally generic. I see the same issue logged out in an incognito window.
With the explicit useskin=vector URL, the high-order digits overflow onto the grey left-side navbar, but they're visible on both the 6a and the X4.
Both of my examples are using Chrome.
On my Moto X4 running Android 9, there's enough room for 3 digits, so this appears to be browser or device specific.