When I load http://localhost:3000 in Safari, Safari automatically redirects to https://localhost:3000. How can I disable this functionality?
I went into ~/Library/Cookies/HSTS.plist and removed the localhost entry, then restarted Safari but it just re-added it to that plist file and redirected to https.
Any ideas how to fix this so that on localhost I have to explicitly say http or https?
I was able to solve this based on an answer from Ask Different.
In short, closing Safari, then running the commands below, worked.
sudo killall nsurlstoraged
rm -f ~/Library/Cookies/HSTS.plist
launchctl start /System/Library/LaunchAgents/com.apple.nsurlstoraged.plist
Restarting Safari after running that and trying to go to http://localhost:3000 solved the problem and did not redirect to to https.
Hopefully this helps someone fix this problem.
In Safari 13.0.5, deleting website data for localhost (Safari > Preferences > Privacy > Manage Website Data...) solves the problem.
This also happens if the Content Security Policy "upgrade-insecure-requests" is set. There is an open issue here: https://github.com/github/secure_headers/issues/348
You can try
deleting website data for localhost (Safari > Preferences > Privacy > Manage Website Data...)
After that close browser and try it.
If cannot you can try make different port 80 after back port 80 for localhost
After following the fix by Charlie with no luck, what worked for me was running a private window. and after a restart, everything seemed fine on both private and public tabs.
It's possible to use http://127.0.0.1:3000 instead. Or your local computer name.
For example: http://andis-mac-5.local:3000.
You can determine the local computer name from system preferences - Share - Edit:
First of all lets confirm why it is going to HTTPS.
In Developer Tools is it showing a 301 or 302 redirect?
If so it's your web server saying to go to HTTPS. Fix your web server config.
Or is it a 307 redirect which indicates HSTS?
To be perfectly honest I'm not sure if Safari shows this as a 307 (a fake internal redirect to represent HSTS), so it might just go there without showing this, but Chrome does show this.
If so, then deleting that file and restarting should solve that. However can you confirm if the HTTPS site is returning a strict-transport-security HTTP Header? If so then it will just set that next time you happen to go to HTTPS (including if your page loads and image over HTTPS). Can you remove that header? Or better yet, publish it with a max-age of 0 so it removes it from the HSTS browser cache without having to figure out which file it's in or if Safari have moved it from ~/Library/Cookies/HSTS.plist
Related
I'm setting up a test environment that does not support https. The problem is, http://localhost/simulator.aspx#!/data keeps redirecting to https://localhost/simulator.aspx#!/data.
I have tried the following steps:
going to chrome://net-internals/#hstsand deleting localhost and 127.0.0.1
Empty Cache and Hard Reload (https://galaxyinternet.us/google-chrome-redirects-localhost-to-https-fix/)
removing cached images and files in chrome://settings/clearBrowserData
nuking C:/Users/Appdata/local/Google/Chrome
Checking the disable cache in Chrome developer tools> network tab.
going to task manager and killing the Chrome process to restart.
This didn't change anything, so I tried it in an incognito window. That didn't work either.
Any ideas?
I am developing a website using Roots.io stack (Trellis + Bedrock + Sage).
I am working, locally, on several sites and they're all working fine. Until today I reboot my computer > execute vagrant up > attempt to access the local development URL https://mysite.dev > but suddenly get an error, in Chrome, stating "NET::ERR_CERT_AUTHORITY_INVALID".
Normally, I do get a similar error, but I have the option to dismiss it. But now I do not.
Via BrowserSync, I can access the site via localhost:3000 but not using the development URL.
If you're familiar with Roots, you know that Trellis generates the SSL locally as self-signed in an automated process. So I know very little about how it works outside of their documentation.
I understand that this issue seems to be a mix-match with the SSL certificates locally, but I don't really know how to troubleshoot that. I'm thinking there is a file locally that needs to be deleted and replaced. But I don't know how to generate a replacement if that's the case.
I have spent about an hour reading any articles I could find on the topic but none seem to really explain precisely what's going on in a way I can apply.
Update: Ultimately I'm looking for a way to add an exception for the ticket in Chrome. I was able to do it in Firefox and it's working there.
Thank you.
Short Answer: Don't use .dev extensions in your local URLs as this is now a real domain name extension no longer reserved for localhost.
Long Answer: https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/
You can either
Import this certificate using Chrome's Options > Manage Certificates > Import
Or simply ignore SSL errors launching chrome with args --ignore-certificate-errors like /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --ignore-certificate-errors &> /dev/null & (not recommended).
Phabricator: running over https, doesn't load any images. Firefox reports blocking unencrypted content.
If I click that little shield thingy next to 'https', and select "Disable protection for now" with "Options" button, things seem to work fine.
I added https:// in phabricator.production-uri and phabricator.allowed-uris with no luck.
Found it:
bin/config set phabricator.base-uri https://<your-base-url>
bin/phd restart
I had previously added that https url in phabricator.production-uri and phabricator.allowed-uris (I don't know if that mattered).
Warning: At one point, I was able to complete messup the login screen. Probably because I didn't run bin/phd restart. If that happens, restore phabricator.base-uri to its previous value.
In addition to setting phabricator.base-uri, you may also need to change security.alternate-file-domain to use HTTPS. Read https://secure.phabricator.com/book/phabricator/article/configuring_file_domain/ to find more about this setting.
Alternatively, you can simply delete the setting by running bin/config delete security.alternate-file-domain.
This same issue occurred to me after installing a TLS certificate.
Setting the base-uri option did not work for me, nor did the production or allowed uri options.
What solved it was setting the security.alternate-file-domain parameter to the https url, as explained here: https://secure.phabricator.com/book/phabricator/article/configuring_file_domain/
Perhaps this isn't the optimal solution, but it's not clear what else to do.
My setup: Bitnami Phabricator pre-configured instance over AWS.
Looks like now the way to go is to screate a support/preamble.php which contains nothing but
<?php
$_SERVER['HTTPS'] = true;
as described here
Ok so this may be a dumb question or possibly something that just isn't supported but haven't had much luck finding an answer.
I'm testing out Light Table for use as my day to front end editor and have been trying to get a page loading in the internal browser without success. I have a weblogic server running my app which I can access from Chrome and other browsers but when I try to point Light Table's browser at the same url I get the generic proxy can't connect to destination.
My first thought was that this I needed to configure Light Table to work with the company proxy but I am able to get to other sites from light table using the built in browser and I have the env variables http/https_proxy set. Has anyone seen this issue or know of a fix/workaround?
Ubuntu 14.04
Light Table 0.7.0
Chrome 36.0.1985.125
It's weird but sounds "reasonable" that you don't really need any proxy to access localhost. I'd check using 127.0.0.1 in your url rather than localhost if you already didn't.
I recall a weird issue probably unrelated on Ubuntu that prevented the right name resolution. The resume is to check that /etc/hosts should contain just 127.0.0.1 localhost rather than your_machine_name 127.0.0.1
lein repl error:Connection refused
I used to run web applications all the time on my laptop, no problems, I am using VWD 2008 Express, i have the latest framework, Windows Vista Home Basic...etc..
Now, when ever i try to run a website, or even chose to Show a Page in Browser from Within VWD, the browser (both IE and Firefox) keeps looking for www.localhost.com...
I tried to copy the address of and paste it directly in the title bar, nothing, same problem i tried to get that address from the balloon notification (the one that pops up when you run any ASP.net project), still nothing happens...
My colleague is facing the same problem, but for him, he can simply copy and paste the url in the address bar, but its not working with me....Heeeeeellllllllllllllllp
Check your hosts file, it should be redirecting localhost to 127.0.0.1 and nothing else. The entry that will cause this error should look like this:
127.0.0.1 www.localhost.com
If you find this, remove it or change www.localhost.com to localhost.
You can also try to post one of these in the adress bar:
127.0.0.1
http://localhost
Note that the hosts file is a popular victim of viruses, so if is has been modified, you might run a check on viruses.
Also see the discussion here.
If that also doesn't work, open up nod32 (you probably have it installed on your system if the above methods don't work) go to advanced setup, on the left menu, select protocol filtering, and select HTTP and POP3 ports... ;)
I got the same problem in firefox 3.6 when my server was down.
In my case it was not a problem with etc/hosts where the line
127.0.0.1 localhost
was there and OK.
The solution that worked for me was to disable the "cleaver" URL fixing that Firefox carry out when the page is not found. The procedure taken from here:
Type about:config in the address bar and hit return.
find browser.fixup.alternate.enabled
double click the “true” value. The line will become bold, and the
value will change to “false”
This fix directly the problem. No firefox restart needed. If your server is down you get "page not found" as expected.
Hope it helps.
Thank you for your solution ... this works fine...
I got the same problem in firefox 3.6
when my server was down. In my case it
was not a problem with etc/hosts where
the line
127.0.0.1 localhost
was there and OK.
The solution that worked for me was to
disable the "cleaver" URL fixing that
Firefox carry out when the page is not
found. The procedure taken from here:
1. Type about:config in the address bar and hit return.
2. find browser.fixup.alternate.enabled
3. double click the “true” value. The line will become bold, and
the value will change to “false”
This fix directly the problem. No
firefox restart needed. If your server
is down you get "page not found" as
expected. Hope it helps. link|flag
answered Sep 3 at 7:55 joaquin
2,237112
A couple of random things to check...
localhost is the conventional name for the IP address 127.0.0.1. If that address doesn't work, then you have a network configuration problem.
There will be a hosts file somewhere, probably in somewhere like C:\Windows\System32\Drivers\Etc\hosts which should usually contain only that definition for localhost. If it has more names in it and you didn't put them there, then you have another problem entirely.
There is also the forehead-slapping possibility that your web server is not currently running. :)