Last modified: 2013-10-11 12:51:47 UTC
This has happened to me three times now, and when I brought it up in #wikimedia-tech, User:Quiddity confirmed it. Basically, we've gone to wikis where we weren't already centrally logged in (for me, at least, always going to a specific page there, not just the main page) and wound up at Special:AbuseFilter. My three were: * http://hi.wikipedia.org/w/index.php?title=%E0%A4%B5%E0%A4%BF%E0%A4%B6%E0%A5%87%E0%A4%B7:%E0%A4%B2%E0%A5%89%E0%A4%97/rights&dir=prev&offset=20120307150502&limit=43&type=rights * https://frr.wikipedia.org/wiki/Wikipedia:Biskiir_Rochtsthemen * https://roa-tara.wikipedia.org/wiki/Wikipedia:Disclaimer_legale Quiddity says he doesn't remember which page he was looking at. This was apparently my first time visiting frr or roa-tara (or at least the first time that my account was activated there), but I've had an account on hi.wp since January Setting severity as "major," since this is very unexpected and confusing behavior, and could be indicative of larger problems.
Confirmed/duplicated, just now. I clicked on the "User contributions" links for a dozen projects, from https://toolserver.org/~luxo/contributions/contributions.php?user=Anthere&blocks=true&lang= Most worked properly, but at io.wikipedia and ckb.wikipedia I was instead sent to their AbuseFilter pages https://io.wikipedia.org/wiki/Specala:AbuseFilter https://ckb.wikipedia.org/wiki/%D8%AA%D8%A7%DB%8C%D8%A8%DB%95%D8%AA:AbuseFilter However, the second time I clicked the same links, for those 2 projects, I was sent to the correct destination.
The issue for Khmer Wikipedia mentioned at https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&oldid=102902701#Abuse_filter_in_the_Khmer_Wikipedia might be the same underlying reason.
The redirect being served seems consistent with a redirect from OutputPage: it has no body text, but does have a "Vary: Accept-Encoding,X-Forwarded-Proto,Cookie" header. I also note that "AbuseFilter" is alphabetically the first special page, although it doesn't seem that the special page listing functions return their lists sorted. I doubt this has to do with CentralAuth, though, since CentralAuth only issues redirects from its special pages and from the UserLoginComplete hook (which is only called from Special:Userlogin and from the API's action=login) and since it occurs even in cases where CentralAuth isn't creating an account (e.g. T.H. Kelly on hiwiki, and some of my tests clicking links from Special:CentralAuth/Anomie) but seemingly cannot be repeated even by deleting all cookies. More likely is that some other extension is trying to do something on a user's initial login to a wiki and is somehow screwing it up. But I can't find what might be doing it.
I agree, it doesn't seem like CentralAuth could do this, but it does only happen on autocreates, which is done by CentralAuth. The issue is happening on beta too, so I'll try and figure out how to get a trace from there, and we'll hopefully be able to see what's going on.
(In reply to comment #4) > I agree, it doesn't seem like CentralAuth could do this, but it does only > happen on autocreates, which is done by CentralAuth. Well, no, not just autocreates. While my account was autocreated on frr and roa-tara (and, today, xmf and scn, where it happened again), I've had a hi.wp account since January 24 ([[Special:CentralAuth/PinkAmpersand]]). However, it might have been the first time I visited hi.wp since auto-log-in went live.
(In reply to comment #5) > (In reply to comment #4) > > I agree, it doesn't seem like CentralAuth could do this, but it does only > > happen on autocreates, which is done by CentralAuth. > > Well, no, not just autocreates. While my account was autocreated on frr and > roa-tara (and, today, xmf and scn, where it happened again), I've had a hi.wp > account since January 24 ([[Special:CentralAuth/PinkAmpersand]]). However, it > might have been the first time I visited hi.wp since auto-log-in went live. I also had it happen on a few different wikis, when I was testing by clicking from [[Special:CentralAuth/Anomie]]. But it didn't happen for all of the links. I wonder if it's something as simple as "account created after X date" for the ones it happens on, or "0 edits" or something.
*** Bug 54345 has been marked as a duplicate of this bug. ***
*** Bug 53329 has been marked as a duplicate of this bug. ***
csteipp / bjorsch: Did you manage to investigate?
I haven't found anything new since comment 3. Until just now, anyway. Here are some sample request and response headers, in case they help anyone: GET /wiki/%E1%83%A1%E1%83%90%E1%83%9C%E1%83%A2%E1%83%98 HTTP/1.1 User-Agent: curl/7.32.0 Host: xmf.wikipedia.org Accept: */* Cookie: centralauth_User=Anomie; centralauth_Token=REDACTED HTTP/1.1 301 Moved Permanently Server: nginx/1.1.19 Date: Mon, 30 Sep 2013 16:50:16 GMT Content-Type: text/html; charset=utf-8 Content-Length: 0 Connection: keep-alive X-Content-Type-Options: nosniff Cache-Control: private, s-maxage=0, max-age=0, must-revalidate Set-Cookie: xmfwikiSession=REDACTED; path=/; secure; HttpOnly Vary: Accept-Encoding,X-Forwarded-Proto,Cookie Expires: Thu, 01 Jan 1970 00:00:00 GMT Last-Modified: Mon, 30 Sep 2013 16:50:16 GMT Location: https://xmf.wikipedia.org/wiki/%E1%83%A1%E1%83%9E%E1%83%94%E1%83%AA%E1%83%98%E1%83%90%E1%83%9A%E1%83%A3%E1%83%A0%E1%83%98:AbuseFilter X-Cache: MISS from cp1006.eqiad.wmnet X-Cache-Lookup: MISS from cp1006.eqiad.wmnet:3128 X-Cache: MISS from cp1010.eqiad.wmnet X-Cache-Lookup: MISS from cp1010.eqiad.wmnet:80 As I mentioned earlier, that bears all the signs of coming from OutputPage. But it's somewhat unusual because OutputPage's default is 302, so we only need to look at places where OutputPage::redirect()'s second parameter is being passed 301. I did just find a possible explanation for this while following up that last comment. I see in AbuseFilter::filterAction() it's setting $wgTitle to Special:AbuseFilter if $wgTitle is null. So if that somehow gets called and then RequestContext::getTitle() gets called before MediaWiki::getTitle() is called in MediaWiki::main() (in the process of setting $wgTitle in the first place), then it will pull in that bogus title from $wgTitle instead of calling MediaWiki::parseTitle(). And then MediaWiki::performRequest() is going to find a mismatch between the title it got from the RequestContext and the title in the request and do a 301 redirect. CentralAuth's auto-creation could certainly do it, and it's possible that the call to $this->context->getUser()->isLoggedIn() added in Gerrit change Iaa9dd210 is causing that to happen before MediaWiki::main() sets $wgTitle where before it didn't happen until something later unstubbed the User. Although there must be something else getting into AbuseFilter::filterAction() early in some rare cases. At any rate, if all that is the cause then the fix belongs in AbuseFilter, it should clear $wgTitle if it set it in the first place. I'll submit a patch to do that in a few minutes.
Change 86707 had a related patch set uploaded by Anomie: Reset $wgTitle in AbuseFilter::filterAction() https://gerrit.wikimedia.org/r/86707
Change 86707 merged by jenkins-bot: Reset $wgTitle in AbuseFilter::filterAction() https://gerrit.wikimedia.org/r/86707
Change 88203 had a related patch set uploaded by CSteipp: Move forceHTTPS check until after wgTitle is setup https://gerrit.wikimedia.org/r/88203
Change 88203 merged by jenkins-bot: Move forceHTTPS check until after wgTitle is setup https://gerrit.wikimedia.org/r/88203
Change 88508 had a related patch set uploaded by Reedy: Move forceHTTPS check until after wgTitle is setup https://gerrit.wikimedia.org/r/88508
Change 88508 merged by jenkins-bot: Move forceHTTPS check until after wgTitle is setup https://gerrit.wikimedia.org/r/88508
Is this fixed now?
It seems so, yes.
