A few months ago we received a support query from a user who was unable to log in. We couldn’t replicate the issue and they weren’t able to work with us to get it fixed. We concluded that they were doing something unique and had ended up fixing it from their end somehow.
Fast forward to March 5th, when we sent email invitations for a
Nairobi Linux Users Group meet-up with an HTTP—not HTTPS—link to the login
http://ona.io/login, and got a complaint that the site did not redirect
to HTTPS on the
/join routes. This was a serious problem because we only perform sign-ups, log-ins or any
other form of data exchange over HTTPS, including setting cookies.
When we find the user’s authentication cookies are not set, or are expired, we reload the page so that they can get a new authentication cookie. We implemented this as shown below, by checking for a 401 status from the OnaData API. More of that code is here.
As a consequence of this setup, when a user connects over HTTP and is not redirected to HTTPS they can end up in an endless loop of reloads when they try to sign-up, log-in or submit data in any other way. When we tried it ourselves, HTTP redirected to HTTPS just fine. However, we noticed that it didn’t redirect on a fresh Firefox install, assuming this fresh install didn’t have add-ons like HTTPS Everywhere.