chrome wont let me access localhost (it google searches instead) - google-chrome

How can I disable chrome using address bar for google search?
I cant access localhost at 0.0.0.0:6000, because chrome thinks it's a google search and not an url
any ideas?

This may be because a url was added to your search history. Google is doing you a favor because that's what you did once before somehow.
Try clearing your history to see if this is the case.
I went to "Clear Browsing Data" in Settings > Advanced and I was able to enter a localhost url again.

Be sure you end the url with "/" symbol.
Try:
http://0.0.0.0:6000/
Instead of:
0.0.0.0:6000

SOLUTION For chrome version 62:
settings > advanced > Use a web service to help resolve navigation errors > OFF

Try
- turn off Search Suggestions
- under LAN settings, uncheck "use automatic configuration"
Do you get the same behavior with an incognito window?

Try this alternative: http://127.1.1.1:6000 or 127.1.1.1:6000 (without http).

A search through the web has revealed several different possible causes to this problem as well as solutions.
Causes:
this is malware
this is a chrome/browser issue
this is a misconfiguration of the httpd service
Solutions:
scan for malware, though probably not the issue.
update the host file, so that localhost points to 127.0.0.1
confirm your httpd service is accepting http:// requests through port 80, 8080, or some other port.
make sure the URL has the correct port .. http://localhost:8080
try appending different delimiting characters [ / ? # ] to the URL ...
localhost/Dir/
localhost/Dir?p=x
localhost/Dir#123
does it happen on a specific directory?
localhost/Dir .. works
localhost/Dir2 .. goes to search.
This suggests that the httpd service's configuration may need to be fixed. or that an .htaccess file is the cause. If these problems can be ruled out, then it's a browser issue.
remove the autocomplete entry from the browsers search/address bar
in most cases, type the url, using the arrow keys - highlight the offending entry, press [DELETE] or [SHIFT}+[DELETE].
does your browser support turning off autocomplete or searching from the address bar?
.. chrome .. Disable Predictive Text
.. firefox .. Disable Predictive Text
open the CLI and issue [ >wget localhost/dir ]. Observe what is returned on a working vs non working directory.
Follow up:
This issue is especially annoying when working with .htaccess files and browser redirect statements in PHP, ASP, nodeJS, and JSP which redirect the browser to a specific URL, but instead takes the user to a search page. If at all possible pre-pend http:// and post-pend a slash (/) after the URL in redirects.
http://localhost/dir/
And, YES ... it is annoying to have to add extra characters (as a work around) to get URLs to work right.

I might be a bit late to the party here but I just encountered this same problem on the current chrome (v. 96.0.4664.93) and could it would not resolve any local address using any of the other methods that I found on the web(http://192.168.178.1 or setting flags or insecure DNS).
What solved the problem, was a simple "/" at the beginning of the query string.
Whenever I enter
/192.168.178.1
into the Omnibox and hit enter it works for all services.
If some other people could verify this - I'd be really happy to get some feedback on this approach.

I have this problem often myself. First, go to just localhost, chrome should understand that, then, when you type in localhost/my/url/here, the context will allow chrome to understand to treat it as a url.

Related

Really strange permissions issue on page titles with slashes

I'm using:
mediawiki 1.34
php 7.4
apache 2.4.46
mysql 8.0.22
The problem that I'm having is that I get permissions denied errors from the api when I try to edit, move, or delete pages that have a "/" in its title. This happens through the UI and in some cases things just fail silently and I had to open up the browser's dev tools to look at the network tab.
This has been happening for a while now and we've managed to just not use "/" in any of the page titles, but recently the Translate extension was installed and has been causing issues because translations are stored in pages like title/segment/lang.
Saving a translation POSTs this data:
action=edit&
format=json&
title=Translations%3ATest%2FPage+display+title%2Fes&
text=asdasdsasd&
summary=&
assert=user&
token=XXXX19%2B%5C
and it returns this from api.php:
{
"error":
{
"code":"permissiondenied",
"info":"You are not allowed to execute the action you have requested.",
"*":"See https://localhost/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes."
}
}
The user definitely has all of the translation permissions set, this happens even if I set all translate extension permissions to true for "*".
Does anyone possibly know what could be causing these issues? Or if there's some way to debug this to isolate what permission and where it's being checked? It looks like everything else works fine. I don't have very much experience with mediawiki, someone else used to manage it but they've left.
Try adding AllowEncodedSlashes NoDecode to your Apache config, and nocanon to the ProxyPass directive in it.

"unsafely-treat-insecure-origin-as-secure" flag is not working on Chrome

I am using geo-location for a site running locally on my machine using HTTP on Chrome. However this does not work as I am running on HTTP as opposed to HTTPS.
On the console it says:
getCurrentPosition() and watchPosition() no longer work on insecure origins.
To use this feature, you should consider switching your application to a
secure origin, such as HTTPS. See https://sites.google.com/a/chromium.org/dev/Home/chromium-security/deprecating-powerful-features-on-insecure-origins
for more details.
Accoriding to Deprecating Powerful Features on Insecure Origins its says to start chrome using --unsafely-treat-insecure-origin-as-secure="http://example.com" flag. The command I ran was similar to:
chrome.exe --unsafely-treat-insecure-origin-as-secure="http://hello.app"
However, the same error message still appears.
How can I fix this issue.
None of the solutions worked for me.
I achieved this by following steps.
Type chrome://flags/#unsafely-treat-insecure-origin-as-secure in the address bar.
Add the origin which you need to treat as secure as shown in the below image.
Relaunch chrome.
You must have missed some steps. Try to follow this
Go to File Explorer then paste this to address bar >> C:\Program Files (x86)\Google\Chrome\Application (or just go to where you can find your chrome.exe)
Right click chrome.exe > send to > Desktop (Create Shortcut)
Go to your desktop then find the chrome shortcut you've created.
Rename it to ChromeForTesting (this step is optional)
Right click the shortcut, then Click Properties
At the "Target", paste the following at the end of the link
--user-data-dir=/tmp/foo --unsafely-treat-insecure-origin-as-secure=http://example.com
so Target should look somewhat similar to this
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --user-data-dir=/tmp/foo --unsafely-treat-insecure-origin-as-secure=http://example.com
Click Ok..
During testing close all of your opened google chrome browser.
Then double click ChromeForTesting shortcut (the one you've created), when a prompt appears, just click ok..
EDIT: If the steps above does not work for you, you might be using Chrome V63, update it to V64 above cause this flag is messed up in V63.
P.S. If it's still not working follow these extra steps
At your drive C, create a folder and name it "ChromeTempFiles".
Then in your --user-data-dir= you change the value into "C:\ChromeTempFiles"
Add these to your target as well
--allow-running-insecure-content --reduce-security-for-testing
so your target should look like this now
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --user-data-dir=C:\ChromeTempFiles --unsafely-treat-insecure-origin-as-secure=http://example.com --allow-running-insecure-content --reduce-security-for-testing
You should also use a temproary fresh profile for that session. something like this:
chrome.exe --user-data-dir=/test/only/profile/dir --unsafely-treat-insecure-origin-as-secure="http://example.com"
Just an update to this for Chrome 70. This works perfectly
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --user-data-dir=C:\ChromeTempFiles --allow-running-insecure-content
Now does anybody know if there is an equivalent for firefox?
For Chromium 44 use
--unsafety-treat-insecure-origin-as-secure=http://192.168.0.101:3000
instead
--unsafely-treat-insecure-origin-as-secure=http://192.168.0.101:3000
See that bug
In Google Chrome, you simply type into the address bar, "chrome://flags", and search for, "--unsafely-treat-insecure-origin-as-secure", enable that flag, and enter into the field below (multiples may be entered separated by a comma) the domain you wish to treat as secure. This may or may not compromise your security, but I would assume not as getCurrentPosition() and watchPosition() are somewhat recently deprecated features. this works for publicly served domains, as well.
With Chrome 79 this setting doesn't work no matter what.
What I ended up doing was to configure the domain on a VPS to show some test webpage and then generate a valid certificate for it using Let's Encrypt's certbot.
Then I copied that certificate to my machine and it's now valid.

Attackers might be trying to steal your information from (for example, passwords, messages, or credit cards). NET::ERR_CERT_COMMON_NAME_INVALID

I'm getting the following error for one specific website (and only one specific website):
I've tried the following:
Making sure my time / data settings are correct
Clearing all browsing data
Deleting and reinstalling Chrome
Nothing works. Interestingly, I only get this error for one specific site (www.datacamp.com). And when I turn off wi-fi and tether my iPhone, I'm able to get through to the site. When I turn my wi-fi back on, I get errors again.
When I view details I see this:
And when I view the certificate I see this:
I've tried deleting the certificate, but I get the following message:
Any help is greatly appreciated!
If you are getting this error when access localhost, simply go to
chrome://flags/
and enable Allow invalid certificates for resources loaded from localhost.
Ok, I don't know why it took me so long to try this. I just unplugged my modem and router, then plugged them back in. At least for now, it seems to have resolved the issue...
Check your connection's DNS entries. It's likely a adware or malware program modified them.
open network and sharing center
On the left side- click on:
change advanced sharing settings.
click on home or work.
go through and check "turn off" for the first three questions.
turn on password.
Your computer connection was wide open!!!!
Flushing DNS worked for me in Windows 10. Simply open powershell and issue this command:
ipconfig /flushdns
Adding Google DNS 8.8.8.8 and the Cloudflare DNS 1.1.1.1 solved my issue.
If you are facing this while visiting a website, you can follow below.
This might not solve the issue always. But, this is how I solve it around 8/10 times.
To Resolve this on Chrome :
[Approach 1]
Just Click on Proceed to www.xyzxyz.com..(unsafe)
[Approach 2]
Go to : chrome://net-internals/#hsts
Suppose the site for which the error shown is : https://twitter.com/xxx/yyy....
In the "Delete Domain" option, Enter domain as "twitter.com".
Press Delete.
Reload the page you were trying to visit.

Server has a weak ephemeral Diffie-Hellman public key. How to by-pass it?

While I'm trying to visit a specific website (that one: https://login.uj.edu.pl) I'm getting ERR_INVALID_ARGUMENT error. Here is the problem: "Server has a weak ephemeral Diffie-Hellman public key".
More about the issue there: https://productforums.google.com/forum/#!topic/chrome/o3vZD-Mg2Ic
I know that it should be fixed by a webmaster but until it happens I have to access the page every day anyway. I found an extension to Firefox to avoid this error: https://addons.mozilla.org/en-us/firefox/addon/disable-dhe/
Now i want to get rid of the error in Google Chrome (well, Chromium actually). Is there any possibility to make it work? It's my university's page and it can take years for the site administrator to fix that secure connection issue.
What's strange the problem occurs in Linux only, in all the browsers. In Windows, Chrome-OS or Android there is nothing wrong. I know that using insecure connection is wrong but in that case I have no choice.
EDIT:
I cannot accept any solution because the site I was trying to access changed its encryption to the right one. Now I can't test your solutions because the problem is already solved by site admins.
The solution is:
Type in your browser (I tried in Iceweasel)
about:config
Search for
security.ssl3.dhe_rsa_aes_128_sha
security.ssl3.dhe_rsa_aes_256_sha
Set them both to false (just double click to set them to false or true).
That's it!
This solution worked for me:
C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013
The recent release (Sep. 1) to Chrome 45 contains the fix for the Logjam attack as detailed in https://weakdh.org but it introduce this kind of problem.
I found it in this post
Quick hack to get around this issue (Mac OSX)
Run this in commandline to workaround the issue while launching Chrome
Chrome:
open /Applications/Google\ Chrome.app --args --cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013
Canary:
open /Applications/Google\ Chrome\ Canary.app --args --cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013
For Firefox
Go to about:config
Search for security.ssl3.dhe_rsa_aes_128_sha and security.ssl3.dhe_rsa_aes_256_sha
Set them both to false.
NOTE: Permanently fix would be to update the DH key with a length > 1024
Are you by any chance on the Chrome development channel, or possibly the Beta channel? I know that the dev channel currently has some stricter rules on SSL keys, and Beta might as well. You might try getting the stable release from https://www.chromium.org/getting-involved/dev-channel and see if that runs without the error.
Use netsurf (netsurf aur) on that site. I am on the same boat with you. Using Arch and Chromium and Firefox both refuses to enter certain websites. Netsurf can do the job for me.
I have also facing this issue and resolved by #Duccio Fabbri answer,
--cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013
I don't know why this works but it works, for permanent use of this you can follow below step.
Go to browser short cut
Right click and Go to properties
Go to Short cut tab
Go to Target textbox, in this you will find your chrome full path , add above string at the end of path.
and it will look like
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013
Apply and close it.
Now it will work.when you open it next time.
At Fireforx I was facing the same problem, I did the following changes and it worked for me,
Firefox:
Go to about:config from browser tab
Search for security.ssl3.dhe_rsa_aes_128_sha and security.ssl3.dhe_rsa_aes_256_sha parameter.
Set them both to false.
I was also getting this error, I reset the chrome settings to fix it: Settings > show advanced settings > Reset setting
I found the solution for apache tomcat in this stackoverflow question, I just copy the solution:
Just edit 'conf/server.xml' adding the 'ciphers' attribute to your https connector:
<Connector
...
ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA"
...
Practically you're explicitly defining the list of allowed ciphers, excluding the Diffie-Hellman ones (the one with 'DHE' in the name).
Open Server.xml file in your tomcat and set attribute "ciphers"
<Connector port="8007" protocol="AJP/1.3" redirectPort="8443" ciphers="SSL_RSA_WITH_RC4_128_SHA" />

Chrome won't loads policies

I'm trying to follow this procedure on Chrome's documentation:
http://www.chromium.org/administrators/linux-quick-start
Yet no policy is loaded by chrome. I tried to create the policies/managed and policies/recomended in /opt/google/chrome also but couldn't load the policies.
Is there any special configuration I have to make in order to load Chrome's policies ?
How can I know for sure what is the right place to put the policy file ?
This is part of a WIP trying to solve this question: Chrome Certificate Selection appears multiple times
It should be some cache or wrong parameter problem. As I discovered in Chrome discussion forum here: https://groups.google.com/a/chromium.org/forum/#!forum/chromium-discuss
in linux, Chrome and Chromiun have the same dir for policies, which is:
/etc/opt/chrome/policies/managed
if you put a valid file there it will load it. Double check the commas and parameters.
I am having the same issue. I placed my setting in
/etc/opt/chrome/policies/managed/managed_policies.json
The contents look like this:
{
“ExternalProtocolDialogShowAlwaysOpenCheckbox”: true
}
The file and all parent directories are readable by all users.
I tried reloading Chrome's policies via the url chrome://policy/ as well as restarting the browser and even the entire machine, but to no avail.
I am on Chrome 80 and Centos 7
What am I missing?
Thanks,
frank
/etc/chromium/policies/managed
this path worked for Chromium