Cht-core: Endless login loop when accessing app via http using ngrok

[abbyad]

Describe the bug
If you access the app via http it generally redirects you to the https version. If you are using ngrok however, eg http://123456.ngrok.io, you get a login screen, but regardless of credentials you'll end up back at the login screen.

To Reproduce
Steps to reproduce the behavior:

1. Set up a local install with the local install instructions
2. Set up ngrok
3. Access the ngrok URL using HTTP
4. See the url has the redirect address with http
5. See that any attempt to log in returns to the blank log in page

Expected behavior
Accessing via http should redirect to https, and login at that point would work as usual.

Environment

• Instance: localhost
• Browser: Chrome
• Client platform: Windows
• App: webapp
• Version: 3.7.0

Additional context
When using ngrok the post login redirect address shows http, not https. From some testing, localhost and *medicmobile.org have the redirect addresses set to https and don't have this problem at all.
If this doesn't affect any other setups we should at least put a note in the documentation to mention that only https should be used.

[garethbowen]

Scheduling. This should be relatively easy to fix. Be careful to redirect to https only when using ngrok when accessing "localhost" or it'll break every dev environment...

[garethbowen]

Potentially a duplicate of #6337

[brad1905]

Could not reproduce on master, we should try to reproduce in 3.11 as branch with fixes hasn't been merged yet, perhaps my environment was wrong

[mrjones-plip]

I was having trouble reproducing the issue and Gareth offered:

I think that issue may only occur if your session is in a specific state, for example, if the redirectUrl parameter is set to http://.... . We also made some changes to the login page recently which may have inadvertently fixed it, so you could try reproducing on the 3.7.0 tag and then compare the difference.

He also mentioned advice for me being the both the JS and Medic new kid on the block:

We have had a string of login loop issues, so take the time to understand how we create and check the session both in API and webapp, Also check how we're doing the http -> https redirect in production to make sure you don't break anything.

[mrjones-plip]

At first pass, I'm actually unable to reproduce this in a vanilla dev environment. Looking at the original env, here's mine (note that client platform is different):

• Instance: localhost
• Browser: Chrome (also Firefox, Chromium, )
• Client platform: Windows Ubuntu
• App: webapp
• Version: 3.7.0 (also master as of b3c6953 when Marc commented or 793380f today's hash)

I was able to very nicely reproduce this by forcing the dev environment to be in prod mode by starting the API with NODE_ENV=production node server.js. This in turn sets the secure flag (same in 3.7.0 or master) for all cookies so when you login with a POST to /medic/login to port 80, then the redirect value from the URL gets processed, sends you to port 443/https, the app sees you're not logged in, and sends you back to an empty login form with no error messages.

Some possibly interesting notes:

1. When you go to http://b520d680867c.ngrok.io/medic/login?redirect=https%3A%2F%2Fb520d680867c.ngrok.io%2Fadmin%2F and fail to login using production, you're redirected to http://b520d680867c.ngrok.io/medic/login?redirect=%2Fmedic%2F_design%2Fmedic-admin%2F_rewrite%2F and you STILL can't login, despite neither http nor https in the redirect value
2. ngrok is sending the HSTS header:
   curl -s -I http://b520d680867c.ngrok.io/|grep Strict Strict-Transport-Security: max-age=15552000; includeSubDomains
   This means that the __instant__ you go to that URL your browser will cache the HSTS header (as designed) and on subsequent tests, even if you explicitly type http, the browser will change it to https before sending the request. Testing in another browser, clearing your cache or using a new incognito session will ephemerally negate this.
3. Despite the HSTS header, after being redirected to the https URL and presumably getting the header cached, the browser happily continues to POST and reload (GET) from the http URL?!

[mrjones-plip]

After doing some more ad hoc testing and chatting w/ @garethbowen et al., I think we should close this ticket as "can't reproduce". Maybe another dev, QA or @abbyad wants to double check my work?

[abbyad]

I can't reproduce with my local setup right now, so support closing the issue.

[mrjones-plip]

thx @abbyad!