BrowserID and HTTPS conflict?

Question

My flask-webapp was utilizing BrowserId. When I tried to extend my app further by redirecting all incoming requests to HTTPS. The HTTPS redirect worked fine but now the login feature results in a:

login failure: error

What is causing this problem? What might I do to fix it? In case it matters here is my webapp.. I'm deploying on heroku using Gunicorn as the server. Here are the heroku logs for a failed login

Answer 1

I'm not familiar with Flask, but I suspect that this might be due to a problem with redirecting a POST request. In particular the POST request that the front-end sends to the backend in order to verify the assertion.

One thing you could try (to test the above theory) is to have your application not listen on port 80 and only on 443. That way there won't be a mix of HTTP and HTTPS and flask-sslify will not have to redirect anything.

Answer 2

One thing you can try is to try modifying the client, to POST directly to HTTPS.

It sounds like what might be happening right now is that the client is POSTing to a HTTP URL; then flask-sslify receives the HTTP request, responds to the client with a redirect, and triggers the client to re-send the POST request to a HTTPS URL.

You should be able to check whether this is what is happening using, e.g., Firebug or Wireshark or any other tool that lets you view what requests the client is making.

If this is what is happening right, one thing you could try is changing the client so that it POSTs via HTTPS directly. In other words, try to change the client so that the initial POST request is submitted over HTTPS, so that it never goes over HTTP and never triggers a redirect. I would suggest trying this, to see if it makes the problem go away. If it does make the problem go away, it gives some hint about where the problem might lie (maybe the client doesn't handle redirects for POSTs in the way you'd want, or maybe there's an issue in flask-sslify; in any case, it's a giant clue that should help debug the problem).

You can verify whether you were successful in ensuring that the client submits the POST initially over HTTPS in the first place, using the same debugging tools (e.g., Firebug or Wireshark).

Generally speaking, having the client use HTTPS directly (if possible) is better than relying upon server-initiated redirects to redirect the client from HTTP to HTTPS. It'll simplify things, and is also more secure. (If the client sends its initial request over HTTP, and you rely upon a server-initiated redirect, then you will still be vulnerable to man-in-the-middle attacks. If the client's initial request is over HTTPS, then you're not vulnerable to man-in-the-middle attacks.) It's possible that simplifying things like this might cause the bug to go away, and it shouldn't be too difficult to check whether that is indeed the case.

On the other hand, if your client is already POSTing directly to HTTPS (if your client never sends any HTTP request in the first place, and there's no server-side redirect), then I don't have the foggiest idea what's going on.