Last modified: 2014-09-23 19:58:02 UTC
I've observed this for a couple weeks now at various times on multiple iOS devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or maybe just Safari; not sure. Steps to repro: 1. On iOS mobile device, type beta labs URL into Safari or follow a link to beta labs from email. 2. Go to login page and enter username/pw. Tap login. You'll get taken to a "Safari cannot open page because it could not connect to the server" page. Makes testing new mobile features very difficult :(
Clarifying that this is just mobile web. The mobile apps intentionally cannot log into beta labs.
I borrowed an iphone 4 and used Safari to login at en.m.wikipedia.beta.wmflabs.org. After logging in I got a strange redirect to www.en.m.wikipedia.beta.wmflabs.org and an error message "Mobile domains are not served from this server IP address." Upon manually entering the URL en.m.wikipedia.beta.wmflabs.org again I found I had logged in successfully. However, the logout button did not work. I may have fat-fingered it, but it only brought me to my user page.
(In reply to Maryana Pinchuk from comment #0) > I've observed this for a couple weeks now at various times on multiple iOS > devices (iPhone 5 and iPad 2). It may be affecting all mobile devices, or > maybe just Safari; not sure. Is it 100% of the time or sporadic?
The beta cluster was barely available since last friday so that might be related. Do you reproduce the issue using a desktop browser?
It's constant now :( And yes, I just repro'ed on desktop Safari, too (good news is desktop Chrome is unaffected).
Changing summary accordingly. Chris or anyone with a Macbook: can you reproduce?
I'm getting redirected to the ssl version of https://en.wikipedia.beta.wmflabs.org when I login using Safari and that is broken. Not sure why the https redirect is happening.
It's currently working for me from an iPhone.
I am guessing that your local browser actually wants to log in securely (beta labs stopped listening for https traffic a while back): https://bugzilla.wikimedia.org/show_bug.cgi?id=68387
On a totally reset installation of Safari going to... http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:UserLogin ... and logging in sporadically fails for me on both desktop and mobile Safari.
I'm seeing the same behavior as Bryan, it's trying to redirect to https://en.m.wikipedia.beta.wmflabs.org/wiki/Main_Page which is failing.
Obvious question: SSL Everywhere installed? If so, tried disabling?
(In reply to Greg Grossmeier from comment #12) > Obvious question: SSL Everywhere installed? If so, tried disabling? I think my Safari is completely stock. I never use it because Safari. :)
(In reply to Maryana Pinchuk from comment #0) > You'll get taken to a "Safari cannot open page because it could not connect > to the server" page. Makes testing new mobile features very difficult :( My stock install of Safari on my laptop also had this problem on my first try logging in to beta labs. :-(
Chris/Tyler: Any ideas on why Safari would be unable to login on Beta Cluster?
My Safari is also stock. It seems that first the user is redirected to Special:CentralLogin/complete and then to Main Page (or wherever they came from). I've seen it fail on both.
(In reply to Ryan Kaldari from comment #10) > On a totally reset installation of Safari going to... > http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:UserLogin > ... and logging in sporadically fails for me on both desktop and mobile > Safari. If it's sporadic, then it might be a cache issue-- someone with a forceHTTPS cookie is hitting the page, the redirect is being served and cached, and varnish is ignoring the vary header. That, or Safari thinks it should always use ssl. We've never sent hsts headers for that domain. I'll try to get someone in the office to use my laptop as a proxy, and I can see what exactly is being sent.
For me, it's redirecting to https on the final CA login redirect. Authentication seems to complete as I can navigate to an http URL from there and I appear to be logged in. GET /wiki/Special:CentralLogin/complete?token=<redacted> HTTP/1.1 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.78.2 (KHTML, like Gecko) Version/7.0.6 Safari/537.78.2 ... HTTP/1.1 302 forced.302 Location: https://en.wikipedia.beta.wmflabs.org/wiki/Special:CentralLogin/complete?token=<redacted> ...
Created attachment 16355 [details] tcpflow log of failed login attempt in Safari (redirected to https)
Created attachment 16356 [details] tcpflow log of successful login attempt in Safari (redirected to https)
Created attachment 16357 [details] tcpflow log of successful login attempt in Safari (no redirect to https)
Chris, I've attached the tcpflow logs from our troubleshooting session. Let me know if there's anything else that would be helpful. A brief summary of what we observed while troubleshooting (Chris, please correct me if this is wrong/incomplete): Safari's behavior seems intermittently incorrect in that it includes the "forceHTTPS=deleted" cookie in requests following the explicit expiration of the cookie. The subsequent submission of the literal "deleted" cookie value causes a redirect to https.
(In reply to Dan Duvall from comment #22) > A brief summary of what we observed while troubleshooting (Chris, please > correct me if this is wrong/incomplete): Safari's behavior seems > intermittently incorrect in that it includes the "forceHTTPS=deleted" cookie > in requests following the explicit expiration of the cookie. The subsequent > submission of the literal "deleted" cookie value causes a redirect to https. Yep, that's all correct. On the MediaWiki side, we check for the presence of a forceHTTPS cookie in MediaWiki.php, so when safari hands us back the cookie forceHTTPS=deleted, it triggers the redirect to https. The check could ensure that the cookie value isn't "deleted", since we set it to 1 when we want users to stay in https.
