I've noticed that Google keeps visiting some of my url:s each time i boot up Google Chrome, does anyone know why this might be?
This wouldn't be much of a problem, except that it keeps hitting an login-url for a system I've built. And each time there's an unknown login-call I receive a text message... so, it's kind of annoying.
The IP range i keep receiving this visits from is 66.102.9.*.
Sure, I could block this ip-range. But first I'd like to know why I keep receiving this visits. Does anyone have any ideas?
Perhaps it is your Chrome's starting page and you could change it in the settings.
That's where I'd start, unless you have already checked that.
If that's not it, try the Google Chrome forums
When you use Google Chrome, it sends GET requests to Google's servers for the bowser's update checks and for the Chrome apps updates.
Chrome sends requests to multiple URLs when it’s checking for and downloading updates. The order of requests is determined dynamically at runtime. Both HTTP and HTTPS protocols might be tried. The following URL list of hostnames and paths can change at any time without notice:
www.google.com/dl/*
*.gvt1.com
tools.google.com/service/update2
dl.google.com/*
google.com/dl/*
clients2.google.com
update.googleapis.com/service/update2
Related
I tried to run Google Page Speed Insights and got this error message. I've searched and can't seem to find how to fix that. I also ran Page Speed Insights with other websites that I made and every time it worked.
Lighthouse returned error: FAILED_DOCUMENT_REQUEST. Lighthouse was unable to reliably load the page you requested. Make sure you are testing the correct URL and that the server is properly responding to all requests. (Details: net::ERR_CONNECTION_FAILED)
https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fexecfarm.com%2F
Several of us in comments
have tried the link you gave and have not experienced any errors.
However, I have been refreshing the page and the Google Speed insights result has been showing different values for the page overall score From 34%, to 40% to 70% (then back to 40%).
This would possibly imply that the page is being worked on or that there is some other (database) stuff that is changing each time the page is loaded.
If you are not cloudhosting (ie Cached copies) then when your server is taking up a new file uploaded from your IDE, while that file is uploaded to the server it can not be "read" while it's being "written". So maybe Google is trying to access the file when it is being replaced which will cause momentary drops.
You should also be forcing the HTTPS, currently the website is still fully accessible on the insecure http://execfarm.com URL.
try to force redirection to https instead of http by activate SSL
I tried the test 10 times and all of them failed with
Lighthouse returned error: FAILED_DOCUMENT_REQUEST. Lighthouse was unable to reliably load the page you requested. Make sure you are testing the correct URL and that the server is properly responding to all requests. (Details: net::ERR_CONNECTION_FAILED)
This could mean multiple things. Either your page failed to render in Google's PageSpeed Insights, an internet backbone broke, or something else happened.
It may be that an internet backbone outage that caused your server's connection with Google to be broken. When an internet backbone outage happens, user A may be able to connect to your server, but user B may not. To rule this out, check your logs when you go to your Google PageSpeed Insights and look for any IP address associated with Google's IPs.
To rule out that page rendering is the cause, move your index.html file to somewhere else, and replace it with a dummy index.html, to ensure that page rendering isn't the cause.
To rule out an internet backbone outage, switch to a temporary server and move everything there. If Google PageSpeed Insights works, then you know that it was an internet backbone outage.
Hope this helps.
I faced this problem because of my SSL integration. After fixed it, my problem solved. Try to run lighthouse test without SSL.
Also please check this answer:
This issue is quite often reported by many users.
It occurs because of the following issues:
Unresponsive server Unstable internet connection. Please try to rerun
the test then it will work.
For more clear and better result follow instructions in this link.
https://stackoverflow.com/a/53318088/4766521
Since few days we are experiencing an issue in one of our a domain named "id-validation.us".
Google is blocking this domain on browsing from google-chrome. We tried to rectify the issue and found that google blocking all hits which is being done to id-validation.us. We are using a wildcard certificate on this domain and certificate is fine as it is working well on rest of the domain. We tried to remove the code from a web server as well but the result is still same.
Google is throwing below error once you browse the website from google-chrome. Currently, an index.html file is placed on this web-server for this domain but the response is same.
error message
Can someone help me find the solution to this problem?
You may have some automated script that may affect the computer or browser settings. Google recognizes any automatic redirection or setting-changing code in a server/website as malware.
I try to make correct authorization in Chrome App. I followed official tutorial, but I was not able to sign in - every try ended with redirection to settings page and communicate that
Account sign-in details are out of date. Sign in again
After signing in, I got redirection once again to setting page, and after a moment, the same situation happened.
I saw in chrome://identity-internals that token expiration date is set on 0 of Unix time, so it seems error.
I decided to try samples from Google Chrome Github. I installed the GDrive one and it worked fine - till the moment I deleted key from manifest, I found in documentation that this is kind of extension id. Without it, situation is identical to this with my own app. This happens in all samples with chrome.identity - without key, they are unusable, with key works fine.
Had anyone ever similar problem? Maybe this is connected to some kind of additional Origin in Cloud Console? I am not able to find any information about it. I use key from Web Application App, cause when I try to register Chrome Extension I always receive
Invalid appId for type CHROME_EXTENSION:
but in documentation of Chrome Apps is written that I should Web Aplication Keys.
Would be great if anyone could help. I use latest Dev Channel normal Chrome and Canary, same problem on both of them.
Right, the key needs to be there for the API to work. See http://developer.chrome.com/apps/app_identity.html for all the details.
I'm implementing a mutual authentication for my client in order to solve not having to continually whitelist some of the agencies with a dynamic ip. The process works fine in all browsers that I've tried in the Windows environment (Windows 7).
The problem is that there is a popup for every time that the user goes to the site. On most browsers, this is a one time occurrence, when you first go to the site for the day. On Google Chrome, however, the popup occurs on what appears to be every POST/GET request. I found how to disable the popup for IE and FF with this link: http://docs.threerings.org.uk/wiki/Certificates_without_prompting, but there is still the problem with Chrome.
I've tried to install the certificate into the Trusted Root Certification Authorities, but I get an error message, "The import failed because the store was read-only, the store was full, or the store did not open correctly.".
If anyone has an idea on what I can do to get around the pop-up for Chrome, it would be greatly appreciated.
This is what you're looking for:
http://www.chromium.org/administrators/policy-list-3#AutoSelectCertificateForUrls
I could tell you how to do it exactly, but my honest opinion is that this is something you have to work out yourself. You need to know what is going on because you are more than likely to run into bugs (not bugs per-se but some undesired or unwanted results).
I have to admit that Google Chrome and Chromium are great browsers, but when it comes to client certificates, they have a lot of improvements to be made.
Just some extra info on this that may help people.
The first part references the CFBundleIdentifier which you can find in the Contents folder then info.plist. Click you Application and then show package contents then you should see it.
So I had to do this for Chromium for Tizen debugging below worked obviously use your CN name.
defaults write org.chromium.Chromium AutoSelectCertificateForUrls -array-add -string '{"pattern":"*","filter":{"ISSUER":{"CN":"Entrust Certification Authority"}}}'
I spent the day debugging my website, because I seem to be getting randomly logged out, but just on Chrome on Android.
After reviewing the server logs, I see requests from my Android tablets IP hitting my server for links that I never clicked on. After some experimentation I see every couple of links I click, Chrome will fetch another link at random in the page that was not clicked.
The issue is that there is an a link in the page with an href="logout" which will sign in, and Chrome calls this all on its own, disconnecting the session. I suppose if I changed the link to call a POST operation Google would not fetch it, but I can't see why Google would be fetching links that were not clicked.
This is very odd, and does not occur on Firefox, or Chrome on Windows.
Not sure if this is some sort of virus on the tablet, or some thing Google is doing to check the content of pages that it would not have access to without the session.
I have seen Google do this before, but only when there were Google ads in the page, then Google would fetch the links twice so that it could get the page content to choose the ad. This seems a huge privacy issue, as Chrome is fetching private data from the session.
So the issue is that Chrome is using a new feature "prefetching".
This is a "feature" that will have Chrome randomly fetch any linked URL from the page.
This seems like a very error prone "feature" for Chrome to enable by default. Seems like it could give the user cached or stale data, or change the server's state causing obscure difficult to debug issues. This will also use double the amount of the user's data (and server's CPU), which you would think would not be desirable to most users that pay for their data.
I confirmed this by disabling the feature in Chrome.
My solution was to switch the logout call to use a POST through a element.
See, https://www.technipages.com/google-chrome-prefetch