Redirect All HTTP Traffic to HTTPS in Express to Ensure All Responses are Secure
In the previous lesson, we disabled http in favor of https. In this lesson, we'll learn that the default protocol for web browser is http, and we therefore need to provide an http endpoint that redirects the browser to https. We'll do that by setting up a small express application whose sole responsibility is to redirect http urls to https. In doing so, we'll accidentally reintroduce the transmission of our session id over http, which we'll need to fix in our next lesson.
Instructor: [0:00] Now we have our site running over HTTPS. You could see if I refresh the page here, the URL's indeed HTTPS and it is transmitting the session ID over HTTPS.
[0:11] The problem is if I remove HTTPS from the URL and to leave off the particle of the URL such that I only type in localhost.childproxy.com and hit Enter, the site can't be reached. That's because we've [inaudible] HTTPS without adding back in a redirect from HTTP to HTTPS.
[0:32] In order to do that, we can go right back to our application. Right underneath where we're listening already on port 443, we have to add another express application. We could do this by instantiating another app, say const readerApp = express(). Then we'll add some middleware using readerApp.use and this takes in a function.
[0:58] First function's, first parameter's the request. Second parameter is the response. What this application needs to do is it needs to return a response that is a redirect request to the HTTPS version of the same URL, taking our domain parameter and appending the request URL to it.
[1:21] Then we'll listen on port 80, which is our HTTP port. If we've done this correctly, when a request comes in on port 80, it will redirect to HTTPS with our domain, which is localhost.charlesproxy.com, followed by the rest of the URL.
[1:39] If I now refresh, we can see that it has, indeed, loaded up the HTTPS version of the site. It does this by first hitting the HTTP URL, which sends back a 302 with the location of charlesproxy.com/login, which then instructs the browser to make a second request to the HTTPS version of the page.
[2:01] However, we've now introduced another security vulnerability. If you go back to the HTTP request that we've made first, you'll notice that, even though it's a 302, we see that we still transmitted the session ID cookie over HTTP, making it vulnerable to man-in-the-middle attacks. We'll deal with this in the next lesson.