I've just auto-deployed a LAMP stack on Google Compute. Before when I did this successfully I had to enable HTTP and HTTPS. Now it seems like they've changed the interface totally again.
And this time I find the options to enable are greyed out.
I tried accessing my phpmyadmin at [ip address]/phpmyadmin and it timed out...so clearly http and https are not being allowed in....
How do I enable HTTP and HTTPS access?
This is what it looks like right now. Not sure where to go from here as the option is totally greyed out.
Ok, the answer is to hit the EDIT button at the top.
I do express the opinion though that this is the most un-intuitive (yet glossy) interface I've ever used.
I suffer no shame!
You can do the following:
Your instance is associated with the default network. Click on the default link.
This will bring to the default network settings where you should review all the Firewall Rules
Check if there are any firewall rules with tcp:80 or tcp:443 present for traffic. This will allow access from outside via http, https. If not, click on Add Firewall Rule and then provide access to those ports.
Alternately, you can also use gcloud to manage your firewall. Refer to gcloud firewall command example here.
Related
When I'm developing using Node's http2 library (which only supports HTTPS, not HTTP), when I open localhost in Chrome, I get a warning screen:
Your connection is not private
Attackers might be trying to steal your information from localhost (for example, passwords, messages or credit cards). Learn more
NET::ERR_CERT_AUTHORITY_INVALID
You have to click "Advanced" then "Proceed to localhost (unsafe)". It gets annoying having to do this during development.
I generated a cert and key for localhost use according to the instructions for Node's http2 module. Is there any way to generate them in such a way that Chrome would actually accept them for localhost? Or is there another easy way to get rid of this warning?
(I'm aware of the option of launching Chrome with --ignore-certificate-errors but I'd prefer not to do this for all websites.)
Try the following:
In Chrome, put in chrome://flags/#allow-insecure-localhost in the address bar.
Enable the option that says "Allow invalid certificates for resources loaded from localhost".
Restart Chrome, and it should allow the site.
You can also type thisisunsafe once you put focus on the website
There are two options you can use to get rid of this annoying thing, which are:
Temporarily Disable SSL Warning
You can go to Google Chrome, input chrome://flags in the address bar and press the Enter key to access advanced settings.
In the next step, find the "Allow invalid certificates for resources loaded from localhost" option and enable it. This method is the same as using --ignore-certificate-errors attribute on your Google Chrome shortcut. It disables the SSL warning for all sites.
It's just a temporary solution and I wouldn't suggest to use this frequently.
(I'm aware of the option of launching Chrome with
--ignore-certificate-errors but I'd prefer not to do this for all websites.)
Install SSL On Your Localhost with OpenSSL
You can install SSL on your localhost with OpenSSL. By using this method, your localhost can run HTTPS without any issue at all. The tutorial is quite long with detailed instructions, you can read it at here.
Source: Fix Your Connection Is Not Private Error In Your Browser - ByteBiteBit.com
I tried too many techniques but nothing works at last i find it while i was learning Webapi.
i was unable to visit to any side beacuse of showing the Error "Your Connection is not Private"......
THE REASON IS You have to enable SSL on your Browser and how you can do it let me share the link..
Just follow the steps
https://www.youtube.com/watch?v=4hb6iD3nP6g&list=PL6n9fhu94yhW7yoUOGNOfHurUE6bpOO2b&index=16
chrome://flags/#allow-insecure-localhost in the address bar.
set it to Enabled
relaunch chrome
result
We are looking for a way to have Chrome bypass the HSTS requirements for our dev environment.
We are working on a project for https://foo.com.
Within our organizations internal dns we have DNS entries for foo.com.dev which points to our internal dev server which has historically allowed us to reach our dev server via https://foo.com.dev. Secure web requests to this site have always been met with a security warning that we have been able to bypass but in a recent build of Chrome it seems that the ability to bypass the warning has been removed. We can continue to use this method in IE but would like to be able to test Chrome as well.
Additionally, developers have been able to use there own machine names as suffixes. For example a https://foo.com.workstation10
Any suggestions would be very welcome because the prospect of reconfiguring our entire dev environment is not a pleasant one.
To be clear - access to these sites are entirely limited to internal users by both firewall setup and dns configuration.
You can try one of the following options:
Send the Strict-Transport-Security header only for foo.com, and do not specify includeSubDomains.
Make self-signed certificates for foo.com.dev on server and import in on your local device's chrome.
If your target domain is restricted only for internal purpose, you can bypass it just typing badidea in the chrome window. Further details are available here
For more details about HSTS refer HSTS RFC
I'm trying to set up GUI access to a linux VM on google compute engine. I've followed the advice here:
https://groups.google.com/forum/#!topic/gce-discussion/tN9oZs8xWps
I can get as far as getting the instance to show up on the "My Computers" section of the CRD app, but it is grayed out.
I'm wondering if I need to mess around with firewall settings, or try a different desktop (I've been trying cinnamon). I'd appreciate any help. Thanks!
You definitely have to open the ports to connect, so you will have to use a firewall rule. Cloud Platform has an implicit deny ingress rule. It is explained in the thread you posted that also if you are using CentOS there is an additional steps to disable a firewall rule.
I'm debugging a local site.
I'm getting the following message in chrome.
Your connection is not private
Attackers might be trying to steal your information from t.buyamerica.com (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_COMMON_NAME_INVALID
This is not new, and normally I just click ADVANCED and Procced ...
but lately it just stuck in a loop and display the error message again.
This is a local site therefore the key-pair is indeed invalid, but is there a way to by-pass this issue without installing a proper https for all my local (vagrant based) servers?
NOTE:
The current by-pass for me is to use the same domain as the original site, so that the local site is www.somesite.com, and the actual site is somesite.com
I solved this issue as follow:
In
System Preference -> Network -> WiFi -> Advanced -> Proxies I saw that Secure Http Proxy (HTTPS) is checked and the value for the proxy is localhost:8888
I unchecked the Secure Http Proxy (HTTPS) and it seems to solve the issue.
NOTE: this is a specific MAC issue that apparently caused by a system upgrade (my current version is 10.10.5 (14F2511) Yosemite, MacBook Air (13-inch, Mid 2012))
I never set a proxy server or run any proxy on localhost:8888
You change your local domain something like http://yourdomain.test.
Don't forget the 'http'. And if you're using .dev, change it to .test
Is the "Use Proxy" option on an HTTP Connection in SSIS 2012 broken when not using credentials?
I have a Web Service task in SSIS 2012 that works well normally. When I modify its HTTP Connection to use a proxy without credentials, it seems to ignore my choice and not use the proxy at all. When I specify credientials, it then uses the proxy.
To figure this out, I set it up both ways, and ran Fiddler with capture off. Fiddler with capture off will still show traffic specifically routed through it as it acts as a proxy.
Below are the screenshots with details. You should be able to reproduce this.
First, I note the port that Fiddler is set up with:
Then, I leave Fiddler running but not capturing:
Then I set up the HTTP connection to use the local Fiddler proxy explicitly:
Then I run the Web Service task, and note that nothing shows up in Fiddler.
This tells me that, in this case, SSIS isn't actually using the Web Proxy as I asked it to. Anyone know why not?
To be sure it is working otherwise, I then set up the HTTP connection to use the local Fiddler proxy explicitly, but this time with credentials.
Then I run the Web service task, and note that the request now appears in Fiddler, as expected. So what was wrong in the earlier example?
It looks like the only way is to make the user name and password blank, but leave the box checked. I was surprised when this worked. I am not sure if this is related to how my particular proxy is set up, so your results may vary.