I’ve found I use these URLs a lot and it’s a bit annoying having to wait sometimes 5 seconds before it even starts to load the page I want. I understand all the steps it’s taking, but would it be possible to optimise? (I’d be happy to help because I know it’s not a priority for you, but I’m a stranger on the internet )
The first redirect switches to HTTPS (as it should) but gives your IP to the DT mind control server - or DTMC for short.
The second redirect tells the DTMC which page you want, to put you in the right mood: dribbling mode for the forum, impulse-purchase mode for the webshop.
The third redirect simply pauses for the DTMC’s effect to fully take on before you hit the page.
this can be skipped… there’s nothing secure about this site and it could easily skip this redirect all together.
in the case of the storefront, for some reason there seems to be an extra / which then redirects to the product page with the right amount of / … this can be fixed…
On my own server at home - which has nothing secure on either and I happily left running as a dumb HTTP server for 15 years - I had to install Nginx as a HTTPS wrapper around it, for one single reason: modern browsers give you increasingly ungodly amounts of shit when you connect to “insecure” sites nowadays.
This annoys me no end, as it’s my own server, it’s running inside my house behind my firewall, and it’s for my family. But now they’re being served with “connection insecure” pages that they can’t even override anymore, with no option to disable it. So… HTTPS and dealing with valid certificates even when you don’t need any of this.
Yes by setting HSTS (Strict Transport Security) header so we directly connect to https. TLS all the things, even if they seem to not need it. There’s at least the threat of man in the middles redirecting to IAR! TLS with HSTS prevents that, it forces TLS even when requesting http links. After loading the page once, browsers will only connect over https.
still requires an extra hit to the server to get that header, then a new TCP pipe for SSL.
buuuttt whhyyyyyy? seriously though, why? in this case the traffic will be a redirect. is that sensitive? i guess it could be … for certain people… maybe… i might reconsider.
should be fixed now. calls to http or https now redirect straight to the product in question with the proper following / so the main site doesn’t have to redirect either… two hops;
I may reconsider the HTTPS thing with HSTS … if a compelling reason can be given for this specific use case
Yes once, but that will be cached by browsers (for as long as you specify) and then it wont try http again.
So it’s always just 1 request, but almost only https.
Why should there be anything unencrypted?
There is no reason not to do that.
no extra request, like explained above
it’s not much work
No in all honesty, this isn’t really a vulnerability, so I dont care too much, but it’s a security enhancement. It might stop a man in the middle attack, a little bit less clear text traffic in the world is good.
Not if you put the site in the HSTS preload list. Make sure HSTS is set up properly, then submit it here and it’ll ship out as an HSTS-enabled site with every browser.
Another possibility (maybe a bit finicky) could we make addresses that could take you to a 404 page (like dngr.us/m1) take us to a search for that string?
I have absolutely no experience with Nginx, but I’m a great hack and I survive at work thanks to my Googlefingers. What I’m trying to say is that this seems like it’s super relevant, but I can’t be sure since I don’t… damnit, I’m rambling.
I think I understand this… but how do you indicate that you want to feed in $request_uri into that regex? What would it be performing the regex on without specifying the source?
)
