6 ms·

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

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:'); }

rubyron 5y ago
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.
ArlenBales 5y ago
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.
- 5e92cb50239222b 5y ago
  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.
- Macha 5y ago
  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.
- fullstackchris 5y ago
  This is a one liner in NGINX...
- Anthony-G 5y ago
  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.
- manigandham 5y ago
  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.
i_like_apis 5y ago
Ironically, isn't the server-side feature usually called "rewites"?
- y4mi 5y ago
  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} 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
gitgud 5y ago
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...
franciscop 5y ago
He fixed it promptly based on HN feedback! https://github.com/kentcdodds/kentcdodds.com/commit/5a747aea11ee4b7f94ef8fab56025a51a9a52355 https://github.com/kentcdodds/kentcdodds.com/commit/5a747aea...

rubyron 5y ago

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.

ArlenBales 5y ago

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.

5e92cb50239222b 5y ago
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.
Macha 5y ago
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.
fullstackchris 5y ago
This is a one liner in NGINX...
Anthony-G 5y ago
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.
manigandham 5y ago
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.

i_like_apis 5y ago

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

y4mi 5y ago
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} 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

gitgud 5y ago

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...

franciscop 5y ago

He fixed it promptly based on HN feedback! https://github.com/kentcdodds/kentcdodds.com/commit/5a747aea11ee4b7f94ef8fab56025a51a9a52355 https://github.com/kentcdodds/kentcdodds.com/commit/5a747aea...