Last modified: 2013-11-01 06:47:17 UTC
While logging into English Wikipedia on Chrome, I was sent to http://wikimediafoundation.org/wiki/Special:CentralLogin/start?token=<token> (I can provide the token if it is helpful) which is an error page: No such special page You have requested an invalid special page. A list of valid special pages can be found at Special pages. Return to Home.
CentralAuth isn't installed on private and fishbowl wikis, so you shouldn't be redirected there as part of the CentralAuth login process...
After I pressed the back button and submitted the login again, I was logged in correctly.
During the testing period, this happened to me once. I figured it was cookie clashing or something.
Can we get pageview stats for wmfwiki:Special:CentralLogin ?
*** Bug 52568 has been marked as a duplicate of this bug. ***
This happened to me today using an old WMF test account, thus bug 52568. My first login attempt showed the http://wikimediafoundation.org/wiki/Special:CentralLogin/start?token=xxx failure page as described here, my second login attempt worked but had an invisible 404 request to http://wikimediafoundation.org/wiki/Special:CentralAutoLogin/checkLoggedIn?wikiid=enwikisource&type=1x1&from=enwiki , and my third attempt didn't request anything from wikimediafoundation.org. Mmm, cookies.
I just experienced this as well, from Wikidata.
(In reply to comment #4) > Can we get pageview stats for wmfwiki:Special:CentralLogin ? Yes but 1) stats for foundationwiki are completely wrong, bug 49266; 2) I doubt anything would be included in the stats by design as they are wiki/* URLs (good) but with a parameter (bad): so it's useless. Anyway you can tets your luck with something like: curl http://dumps.wikimedia.org/other/pagecounts-raw/2013/2013-08/pagecounts-20130816-040010.gz | zcat | grep -E "^www.f.+CentralLogin"
This is still occurring sporadically. Increasing priority, adding Chris & RobLa.
*** Bug 53988 has been marked as a duplicate of this bug. ***
Just got this again.
(Slightly related: bug 54195)
This coincidentally happened in one of the logs posted at bug 54119. The reconstructed headers appear to be as follows (note the ordering of the neaders is probably wrong, due to the way the log is structured). Request to https://login.wikimedia.org/wiki/Special:CentralAutoLogin/checkLoggedIn?wikiid=enwikibooks&proto=https&type=1x1&from=itwiktionary GET /wiki/Special:CentralAutoLogin/checkLoggedIn?wikiid=enwikibooks&proto=https&type=1x1&from=itwiktionary HTTP/1.1 Accept-Encoding: gzip,deflate,sdch Host: login.wikimedia.org Accept-Language: en,en-US;q=0.8,it-IT;q=0.6,it;q=0.4 User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.93 Safari/537.36 Accept: */* Referer: https://it.wiktionary.org/wiki/Pagina_principale Cookie: centralauth_Session=95bfdea3c79796f1ff880e9e6422e722; centralauth_User=Bug+54119+test Connection: keep-alive Response: HTTP/1.1 301 Moved Permanently Date: Tue, 17 Sep 2013 22:50:28 GMT Via: 1.1 sq63.wikimedia.org:3128 (squid/2.7.STABLE9), 1.0 amssq42.esams.wikimedia.org:3128 (squid/2.7.STABLE9), 1.0 amssq46.esams.wikimedia.org:80 (squid/2.7.STABLE9) X-Cache-Lookup: MISS from sq63.wikimedia.org:3128 X-Cache-Lookup: MISS from amssq42.esams.wikimedia.org:3128 X-Cache-Lookup: MISS from amssq46.esams.wikimedia.org:80 Server: nginx/1.1.19 X-Cache: MISS from sq63.wikimedia.org X-Cache: MISS from amssq42.esams.wikimedia.org X-Cache: MISS from amssq46.esams.wikimedia.org Content-Type: text/html; charset=iso-8859-1 Location: http://wikimediafoundation.org/wiki/Special:CentralAutoLogin/checkLoggedIn?wikiid=enwikibooks&proto=https&type=1x1&from=itwiktionary Connection: keep-alive Content-Length: 352 There are several things about this response that are inconsistent with it being generated by CentralAuth: * The status code is 301. CentralAuth generates 302 redirects. * There are no Vary or X-Vary-Options or Cache-Control headers. CentralAuth's redirects go through OutputPage, which always adds these headers on WMF wikis. * There is no X-Content-Type-Options header either. This header is added almost first thing in WebStart.php. * The charset in the Content-Type is iso-8859-1. I'd have expected utf-8. * The redirects generated by OutputPage have an empty body, so I'd expect to see Content-Length: 0, or Content-Length: 20 with Content-Encoding: gzip. But here we have Content-Length: 352 with no Content-Encoding. I also note that other redirects in the log do have the "signature" of being generated by OutputPage. For a similar request to https://login.wikimedia.org/wiki/Special:CentralAutoLogin/validateSession?token=4a8e68b9dc93ea933d38d6e83c01aba41bae8e5&wikiid=mediawikiwiki&type=1x1&from=itwiktionary&proto=https, the response was: HTTP/1.1 301 Moved Permanently Date: Tue, 17 Sep 2013 22:50:31 GMT Via: 1.1 sq63.wikimedia.org:3128 (squid/2.7.STABLE9), 1.0 amssq31.esams.wikimedia.org:3128 (squid/2.7.STABLE9), 1.0 amssq46.esams.wikimedia.org:80 (squid/2.7.STABLE9) X-Cache-Lookup: MISS from sq63.wikimedia.org:3128 X-Cache-Lookup: MISS from amssq31.esams.wikimedia.org:3128 X-Cache-Lookup: MISS from amssq46.esams.wikimedia.org:80 Server: nginx/1.1.19 X-Cache: MISS from sq63.wikimedia.org X-Cache: MISS from amssq31.esams.wikimedia.org X-Cache: MISS from amssq46.esams.wikimedia.org Content-Type: text/html; charset=iso-8859-1 Location: http://wikimediafoundation.org/wiki/Special:CentralAutoLogin/validateSession?token=4a8e68b9dc93ea933d38d6e83c01aba41bae8e5&wikiid=mediawikiwiki&type=1x1&from=itwiktionary&proto=https Connection: keep-alive Content-Length: 406 For a similar request to https://login.wikimedia.org/wiki/Special:CentralAutoLogin/checkLoggedIn?wikiid=enwikivoyage&proto=https&type=1x1&from=itwiktionary: HTTP/1.1 301 Moved Permanently Date: Tue, 17 Sep 2013 22:50:33 GMT Via: 1.1 sq63.wikimedia.org:3128 (squid/2.7.STABLE9), 1.0 amssq37.esams.wikimedia.org:3128 (squid/2.7.STABLE9), 1.0 amssq45.esams.wikimedia.org:80 (squid/2.7.STABLE9) X-Cache-Lookup: MISS from sq63.wikimedia.org:3128 X-Cache-Lookup: MISS from amssq37.esams.wikimedia.org:3128 X-Cache-Lookup: MISS from amssq45.esams.wikimedia.org:80 Server: nginx/1.1.19 X-Cache: MISS from sq63.wikimedia.org X-Cache: MISS from amssq37.esams.wikimedia.org X-Cache: MISS from amssq45.esams.wikimedia.org Content-Type: text/html; charset=iso-8859-1 Location: http://wikimediafoundation.org/wiki/Special:CentralAutoLogin/checkLoggedIn?wikiid=enwikivoyage&proto=https&type=1x1&from=itwiktionary Connection: keep-alive Content-Length: 353 I note that the Content-Lengths seem to correspond to the lengths of the Location, and in fact the differences in the lengths exactly match the differences in the lengths of the Location value after htmlspecialchars() or urlencode() is applied, which would be consistent with a non-empty body that includes a link to the redirect target (i.e. *not* the empty body generated by OutputPage). All this makes me skeptical that this is being caused by something in CentralAuth. And given the lack of a X-Content-Type-Options header too, I suspect the problem is not even in MediaWiki.
(In reply to comment #13) > This coincidentally happened in one of the logs posted at bug 54119. To clarify for the others following: I was not redirected to the wmfwiki page, though such a request happened in the background. I know because I saw that URL, remembered this bug and double-checked.
Hi Brad, interesting observation about CentralAuth. I wonder if there's another extension that's causing issues. Check this out: https://login.wikimedia.org/wiki/Special:Version It seems like one thing we could try is stripping this down to the absolute minimum.
A quick grep through the extensions in 1.22wmf18 doesn't turn up anything likely-looking. Only one extension uses "Location:" (Collection), and that doesn't seem to be doing anything that would force wikimediafoundation.org. Also, I'd expect anything from an extension to at least have the X-Content-Type-Options header set from WebStart.php. Another data point: The responses quoted in comment 13 are consistent with those returned by Apache's RewriteRule with [R=301], including the Content-Length. For example, this command hits one of those and gives a response with Content-Length 352, just as the first response from comment 13 does: curl -kv -H 'Host: bogus.wikimedia.org' 'https://wikimedia-lb.esams.wikimedia.org/wiki/Special:CentralAutoLogin/checkLoggedIn?wikiid=enwikibooks&proto=https&type=1x1&from=itwiktionary' It seems unlikely that the specific redirect rule that example hits is what's being hit though, that would seem to require there be an apache that never got restarted (or never got its copy of operations/apache-config updated) since Gerrit change #62021 was merged in May.
Is this something Ops should be looking into then? If so, can someone file an RT ticket to make this happen?
Just for another datapoint, I got this while scanning a bunch of wikis with phantomjs. Complete headers included. Request: "https://login.wikimedia.org/wiki/Special:CentralAutoLogin/checkLoggedIn?wikiid=aywiki&proto=https&type=script&returnto=Nayriri_u%C3%B1stawi&returntoquery=" Request Headers: User-Agent: Mozilla/5.0 (Unknown; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) PhantomJS/1.9.1 Safari/534.34 Accept: */* Referer: http://ay.wikipedia.org/wiki/Nayriri_u%C3%B1stawi Request Cookies: "domain":"ay.wikipedia.org", "httponly":false, "name":"uls-previous-languages", "path":"/", "secure":false, "value":"%5B%22ay%22%5D" "domain":"ay.wikipedia.org", "httponly":false, "name":"mediaWiki.user.sessionId", "path":"/", "secure":false, "value":"wAX005sEAH3EMyN5dUEH5UNAcj438xQc" "domain":"ay.wikipedia.org", "expires":"Fri, 04 Oct 2013 23:56:48 GMT", "expiry":1380931008, "httponly":false, "name":"centralnotice_bucket", "path":"/", "secure":false, "value":"1-4.2" Redirected (301) to "http://wikimediafoundation.org/wiki/Special:CentralAutoLogin/checkLoggedIn?wikiid=aywiki&proto=https&type=script&returnto=Nayriri_u%C3%B1stawi&returntoquery=" Response Headers: Server: nginx/1.1.19 Date: Fri, 27 Sep 2013 23:56:54 GMT Content-Type: text/html; charset=iso-8859-1 Content-Length: 385 Connection: keep-alive Location: http://wikimediafoundation.org/wiki/Special:CentralAutoLogin/checkLoggedIn?wikiid=aywiki&proto=https&type=script&returnto=Nayriri_u%25C3%25B1stawi&returntoquery= X-Cache: MISS from cp1019.eqiad.wmnet, MISS from cp1016.eqiad.wmnet X-Cache-Lookup: HIT from cp1019.eqiad.wmnet:3128, MISS from cp1016.eqiad.wmnet:80 I'll open an RT ticket.. This really looks like either squid or apache doing something wrong.
I went through the Apache servers with salt to check for existing login.wikimedia.org config and i found one server that was active in load balancing but indeed didn't have a current Apache config. mw1041 was missing in the dsh group "apaches" while it was in other groups (most likely because it had broken hardware in the past). since "sync-apache" uses that dsh group to sync it failed to sync mw1041 and with the older config it returned redirects to wikimediafoundation.org not knowing about login.wikimedia.org i fixed by adding back to dsh groups: https://gerrit.wikimedia.org/r/#/c/86670/ and resyncing it. 15:30 mutante: sync-apache mw1041 and restart apache, was missing in apaches dsh group before: apache-fast-test login.wm.url mw1041 http://login.wikimedia.org/wiki/ * 301 Moved Permanently http://wikimediafoundation.org/wiki/ now: http://login.wikimedia.org/wiki/ * 301 Moved Permanently http://login.wikimedia.org/wiki/Main_Page
I just spidered all wikis, which has previously been a reliable way to reproduce this. I got no redirects to wikimediafoundation.org. So I think that may have been issue. Thanks! Closing this for now. If anyone sees this pop up again, please reopen.
