Hacker News Reader

Comment by nickreese | Hacker News Reader

This seems insanely over-engineered.

Yet, look at the source and the first thing that pops out is:

  // this is a temporary solution until I can figure out a safe way to do this on the server
  if (window.location.protocol === 'http:') {
  window.location.href = window.location.href.replace('http:', 'https:');
  }

View on HN

Surprising that with all that infrastructure he’s not compacting/obfuscating his JS.

Also surprising, of course, that an expert isn’t doing that redirect server-side.

Do browsers even allow this? I thought this would display the red page "INSECURE CONNECTION" warning, I wouldn't think it would run this Javascript too...

He fixed it promptly based on HN feedback!

https://github.com/kentcdodds/kentcdodds.com/commit/5a747aea...

Ironically, isn't the server-side feature usually called "rewites"?

No, it's redirect.

You generally have two "servers" open, one on port 80, another on 443.

Request on port 80 get a http 301 or 302 to https://${server}${request_uri}

Usually both ports are served by the same daemon, but different vhosts/servers or whatever you want to call it

Rewrite would normally map /arbitrary/ to /something-else/ or similar things, generally transparently so the client never notices

To be fair, doing it client side like this is so much easier than setting up all the rewrite rules server side. It's actually kind of funny he chose the least complex route here considering everything else about his site is overly complicated.

What rewrite rules? Caddy does it for you automatically. With nginx it's a single line in the config file. Or throw your site into HSTS preload (ok, you'll have to add a single header to the config) and any modern browser won't even try HTTP.

There are multiple solutions and all of them are even simpler than what he picked.

The point of redirecting to HTTPS is so someone cannot MITM your traffic. HSTS ensures there's only one chance for that to happen as your browser will remember the HTTPS redirect.

This kind of redirect does not provide the same benefit. An attacker could just tamper with the JS to remove that code, and this could happen on any visit, not just the first.

This is a one liner in NGINX...

To add to the sibling comments (not downvoting): if you have a HTTP site served by Apache and use the Apache plugin for certbot to obtain a Let’s Encrypt-signed certificate, certbot also does a good job generating the Apache configuration to enable redirects to the HTTPS version.

This should be done server-side and is a single line with most frameworks or web servers. It actually highlights the central issue here being frontend devs and practices trying to reach into the backend without any experience or knowledge, resulting in an over-complicated mess while solving no real problems.

Reply on news.ycombinator.com