Last modified: 2013-09-27 16:59:05 UTC
Steps I followed to reproduce: 1) Pick or produce an account registered on it.wikt (home), en.wikt, it.source, en.source; clear all cookies and start new incognito window on Chromium (27.0.1453.93 200836) 2) Visit ru.wikt 3) Login on it.wikt 4) Visit ru.wikt I. Expected: I am logged in (account is autocreated). II. Actual: Account is not created and I am not logged in. (Not bug 45578 comment 3 because I had visited the site.) 5) Visit en.wikt III. Expected: I am logged in (account already exists). IV. Actual: I am logged in. 6) Visit it.source Same as III, IV. 7) Visit en.source Same as III, IV. In some previous test I was not logged in at step 7 (i.e. in other projects but same language subdomain, but not same project different language), I don't know what happen. The messy situation at [[Special:CentralAuth/Bug 16864 test]] is due to bug 16864: if you sort by date you can spot the accounts autocreated by logging in on wikimania2013 and outreach (without any logic). I don't know how the various bugs are interacting here.
Probably needs to be retested after https://gerrit.wikimedia.org/r/83655 is deployed
Can't reproduce, tried with both Firefox 24.0 and with Chromium 29.0.1547.57. Although I didn't specifically test having the *home* wiki as itwiktionary. If you can capture the HTTP request and response headers for the following (obscure the values of any cookies with names ending in "Token" or "Session", but please indicate which were the same across requests), that would be helpful: * The POST of the login form on itwiktionary, and all the subsequent redirects * Any calls to Special:CentralAutoLogin on the HTML page from the previous * The request on ruwiktionary after having logged in on itwiktionary * Any calls to Special:CentralAutoLogin on the HTML page from the previous (there shouldn't be any, though) To capture the headers, the information in http://productforums.google.com/forum/#!topic/chrome/1u7DQv-ag_4 may be helpful; note there will be multiple HTTP_TRANSACTION_SEND_REQUEST_HEADERS and HTTP_TRANSACTION_READ_RESPONSE_HEADERS blocks in one URL_REQUEST in the case of redirects.
I reproduced again with steps as above, with [[Special:CentralAuth/Bug_54119_test]]; I stopped at step 4 because that's what you requested. There is no need to obfuscate headers because it's a throw-away account. I forgot to follow the instructions closely on it.wikt login, so I only have HAR files for that and step 0. Note that in step 0 I had to manually login on it.source (but not en.source) to create the account. Attachments follow.
Created attachment 13299 [details] Step 1 (account creation) HARs
Created attachment 13300 [details] Special:CentralAutoLogin calls 1
Created attachment 13301 [details] Special:CentralAutoLogin calls 2
Created attachment 13302 [details] Special:CentralAutoLogin calls step 3
Created attachment 13303 [details] Special:CentralAutoLogin calls step 4
Created attachment 13304 [details] Step 3-4 HARs and URL_REQUEST details
Created attachment 13305 [details] Step 4 net-internals export
So, to expand on the comment above, in the first attempted auto-login after account creation there wasn't any call to login code or special pages that I could see; in step 4 there were some but apparently not successful.
That didn't really help. Looking at the connections to ruwiktionary in attachment 13304 [details], I see all the correct cookies were sent so you *should* have been logged in. ..... Ugh. Have you tried it with a username that isn't caught by ruwiktionary's TitleBlacklist rule ".*\d{5,}.* <newaccountonly> # 5+ digits running", or any of their other very restrictive blacklist rules? Or can you reproduce it on any wiki other than ruwiktionary (or one with the same sort of rules)?
(In reply to comment #12) > That didn't really help. Looking at the connections to ruwiktionary in > attachment 13304 [details], I see all the correct cookies were sent so you > *should* have > been logged in. > > ..... Ugh. Have you tried it with a username that isn't caught by > ruwiktionary's TitleBlacklist rule ".*\d{5,}.* <newaccountonly> # 5+ digits > running", or any of their other very restrictive blacklist rules? Or can you > reproduce it on any wiki other than ruwiktionary (or one with the same sort > of > rules)? Sigh. I chose a random wiki to avoid bias, I should have used one of those super-small languages as I usually do. However, why did I have to manually login on the first of (it|en).source to create the account on step 1? I'll try to reproduce again elsewhere...
(In reply to comment #13) > However, why did I have to manually login on the first of (it|en).source to > create the account on step 1? Possibly bug 54292?
(In reply to comment #14) > (In reply to comment #13) > > However, why did I have to manually login on the first of (it|en).source to > > create the account on step 1? > > Possibly bug 54292? Indeed that bug might be the correct formulation of what I tried to report here. I'll check better later.
I'm going to mark this RESOLVED INVALID, per comment 12 that the main complaint here an issue with one wiki's TitleBlacklist configuration (and the followup complaint in comment 13 seems covered by bug 54292). Feel free to reopen if it can be demonstrated that that's not the case.
(In reply to comment #16) > Feel free to reopen if > it > can be demonstrated that that's not the case. Yes, I planned to retest this after the fix for bug 54292 is deployed.
