We have no customizations, other than css/html. Even after removing those, the bug is still there.
We can’t reproduce. Do you have any plugins or unusual settings in your mobile browser?
I also noted your screenshot does not show the https lock icon. Are you visiting the wrong URL? I believe try can be accessed through both http and https so I strongly suggest using https so nothing can tamper with the requests.
I can reproduce by visiting http://try.discourse.org (not https) on my iPad - account is created (receive confirmation email), but the spinner just keeps on spinning.
So the “bug” is that people are visiting the http version of the site? But how? I can’t even get to the http version. It’s enforced with HSTS.
Compare these screenshots
Notice padlock, meaning https.
➜ discourse git:(master) curl -vv -L http://try.discourse.org/ * Trying 2001:470:1:3a8::201... * Connected to try.discourse.org (2001:470:1:3a8::201) port 80 (#0) > GET / HTTP/1.1 > Host: try.discourse.org > User-Agent: curl/7.47.0 > Accept: */* > < HTTP/1.1 301 Moved Permanently < Content-length: 0 < Location: https://try.discourse.org/ < Connection: close < * Closing connection 0 * Issue another request to this URL: 'https://try.discourse.org/' * Trying 2001:470:1:3a8::201... * Connected to try.discourse.org (2001:470:1:3a8::201) port 443 (#1)
How are ypu able to get
We do both
Interesting… I was on my University network when I managed to repro it - now I’m on my private network I get redirected to https. The university uses the same ‘eduroam’ network used across educational institutions worldwide, so I wouldn’t expect there to be anything too weird about its setup.
When I’m back on campus tomorrow (UK time) I’ll run the curl @Falco just ran and see what I get.
Are you sure you guys aren’t being man-in-the-middle’ed for “security”? Because you are definitely not getting https.
I can’t think of any other explanation.
I reprod on an iPad connected to the enterprise wifi network. There are no ‘profiles’ or ‘certificates’ installed on the iPad, and AntiVirus/firewalls don’t really exist for iOS. So it must be the university proxying the connection and doing weird things in the name of security. Completely ignoring an HTTP 301 redirect does seem a bit extreme though.
It is surprising that so many people are seeing this issue at the same time…
To add some information, this isn’t eduroam itself - it must be network specific. Eduroam is just a system to allow users of any participating university to use their “home” University credentials at another University. It’s just authentication. Eduroam doesn’t redirect, rewrite, or affect traffic in any way. This issue must be “behind” eduroam.
Your campus network is definitely doing something funky, given that you can’t repro the problem unless you’re on the campus network. I would be interested in feedback from the other people reporting the problem as to what sort of network they’re on.
To try and run this down at our end, would anyone seeing this problem on
try.discourse.org please include:
- The exact (to the minute, at least) time the problem occured (preferably in UTC, but at least including a numeric offset timezone);
- The IP address that the requests will be coming from (as reported by http://icanhazip.com/ or similar);
- Your device’s details, including OS version, browser used (and version), and any plugins installed;
- If you have tried to reproduce the problem on multiple devices, please provide the above details for all devices used, and whether it succeeded or failed for each of them;
- A traceroute from your network to
try.discourse.orgwould be very appreciated.
I just tried again.
- I come to the https://try.discourse.org (padlock is there, ofc)
- browse a bit, padlock stays
- click Login, new window appears, click Create new account, padlock still on
- enter info, click create new account, padlock is gone, keeps spinning
Time: 15:41 PST
Device: iPhone 6S, Version iOS 10.2, Latest Safari, no plugins
All other mobile devices work fine.
The padlock might actually be misleading us… the padlock seems to appear/disappear sporadically for me, and I think it’s because one of the images in the header is not being loaded securely
The main logo code at the top of try.discourse.org
<img width="64" height="45" src="https://discourse.org/images/nav-icon.png" alt="logo">
This then gets 302 redirected to a non-secure address
curl -vv -L https://discourse.org/images/nav-icon.png * Trying 22.214.171.124... * TCP_NODELAY set * Connected to discourse.org (126.96.36.199) port 443 (#0) * TLS 1.2 connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 * Server certificate: ssl389619.cloudflaressl.com * Server certificate: COMODO ECC Domain Validation Secure Server CA 2 * Server certificate: COMODO ECC Certification Authority > GET /images/nav-icon.png HTTP/1.1 > Host: discourse.org > User-Agent: curl/7.51.0 > Accept: */* > < HTTP/1.1 302 Found < Date: Fri, 13 Jan 2017 23:57:46 GMT < Content-Length: 0 < Connection: keep-alive < Set-Cookie: __cfduid=d8eedaeec0f7cde48c1545924348047281484351865; expires=Sat, 13-Jan-18 23:57:45 GMT; path=/; domain=.discourse.org; HttpOnly < Cache-Control: no-cache < Location: http://www.discourse.org/images/nav-icon.png < CF-Cache-Status: MISS < Server: cloudflare-nginx < CF-RAY: 320ccad90b4a350c-LHR
This is on a home network, no weird enterprise proxies. I doubt this is the root cause of the topic of this thread, but it’s certainly confusing things!
Thanks for that test, @Doker; I’ve found the relevant requests in the logs, and I’ll pass them on to someone who can do a better dissection than me.
Good catch, @david, on the redirecting image. That redirect should be preserving the HTTPSness of the original request, so obviously something has come unstuck in our haproxy config, so I’ll take a look at that. Also, I’ll look at getting the
src on that link changed, since a spurious redirect isn’t great for performance, regardless of any other considerations.
https://discourse.org/images/nav-icon.png definitely results in an incorrect redirect to http. I think that redirect is coming from CloudFlare though.
edit: for now, I’ve replaced that navigation icon with an image from the CDN.
I’m testing on a home network with no enterprise proxies. On the same network with the same phone, I’ve had it work and not work for me on various occasions. The first time I tried three days ago (screenshot above), I didn’t have the padlock showing and it didn’t work. I’ve tried every day since then, each time I see the padlock and it works no problem. Unfortunately, on our discourse forum that we’re trying to launch (with no customizations, other than css/html), I continue to get the same spinning icon issue even though the accounts are created and activation email sent.
iPhone 6, Version iOS 10.2, Latest Safari, no plugins
I just tested with my phone again and it worked fine; however, I just tested with my wife’s phone and it didn’t work…her details:
Time: 16:44 PST
Device: iPhone 6, Version iOS 10.2, Latest Safari, no plugins
Wait, so you’re saying on the same device it didn’t work before, now it is working?
I definitely changed out the image on try.discourse.org that was getting erroneously redirected to http, but that’s it.
Yes on my phone the first time I tested on try.discourse.org it didn’t work (that was my first screenshot three days ago). Every day I’ve tried since, it has worked for me, including today. However on my wife’s phone, it hasn’t worked at any time (the latest details above). We have the same device, same ioS version, no plugins and obviously on the same home network.
Thanks for that test, especially the different behaviours between devices on the same network. I can see two interactions in our logs a few minutes apart; could you confirm that the first one (at about 16:37 PST) was the successful one from your device, while the second (at about 16:44 PST) was the unsuccessful one from your wife’s device? The two sessions show different behaviours behind the scenes, and I want to make sure we’re correlating the correct ones to successful / unsuccessful interactions.
Can you try in incognito (private) mode to rule out any cookies or anything like that? Another variable is your network. Are you on wifi or cellular? Try switching from one to the other.