4 ms·
When developing a webapp these days, I use a local proxy. This allows me to type a staging/production URL into Chrome, and get the frontend and the backend fro
by lwouis 5y ago
When developing a webapp these days, I use a local proxy.
This allows me to type a staging/production URL into Chrome, and get the frontend and the backend from either my local machine or staging/prod. I can mix and match any combination by checking/unchecking a box in Proxyman.
This means there is no need to whitelist localhost for CORS, and other hoops. Another advantage is that you're experiencing the app with SSL, so you may notice bugs that you would miss if you're used to work with HTTP locally. I've had these bugs which "only happen on production" in the past, and it's a nasty thing to deal with because it will be in a rush, since it happens as a surprise, and impacts users immediately. It can also bypass QA if the QA environment is also using workarounds and not a prod-like setup with SSL and the likes.
I recommend giving it a try. It's a workflow I haven't seen promoted anywhere before.
- raihansaputra 5y agoThanks for the tip for Proxyman!
- tomashubelbauer 5y agoI tried to achieve the same thing in the past and have run across issues with HSTS. The details are escaping me but I think it might have been that when using the production app without a proxy, the SSL certificate was associated with the HSTS records in the browser and when I switched to a proxy, the HSTS started failing because the certificate has changed. Have you run into this at all? How have you solved it?
- llimllib 5y agoI don't develop at the same URL as I publish at - I'll generate keys with mkcert and host my site locally via a proxy at local.realdomainhere.com for a site that has dev.realdomainhere.com and the prod domain www.realdomainhere.com.
- tomashubelbauer 5y agoI see, I misunderstood. My dream setup is one where I have the same URL for TEST/STAG/PROD and just switch which BE the URL resolves to based on some configuration/tool.
- Jiocus 5y agoI have a certain workflow similar to this. 1. Let testing/staging environments present the same, valid certificates and keys as your production domain. Simply keep a copy for your internal use. 2.1 modify /etc/hosts so that production aliases localhost or 2.2 let an internal DNS service do the spoofing work. You'll still need some action to switch between environments. Full ownership of certificates is a recommendation. At your own risk.
- kijin 5y agoHSTS doesn't complain as long as there's a valid certificate. If you ran into problems because of different certificates, you probably had HPKP.
- Steltek 5y agoI run into occasional HSTS issues on my home network sometimes because I've wildcarded HSTS and not everything internal has a cert. It's usually recently arrived IoT stuff that hasn't been cordoned off behind a stronger proxy. Additionally, I run my own internal CA for various reasons and Firefox/Android seems to have stopped recognizing it. Irritating but it's a good razor for whether to upgrade internal or experimental apps to a Let's Encrypt cert.
- Jenk 5y agoAlternatively there are dynamic DNS services like https://sslip.io/ https://sslip.io/, https://nip.io https://nip.io, or if it ever comes back: https://xip.io https://xip.io. They let you use hostnames that redirect, so for example: https://foo.127.0.0.1.sslip.io https://foo.127.0.0.1.sslip.io will redirect to your localhost.