We're using headless Chrome for an application testing. We have a page that refuses to redirect in headless mode but redirects perfectly fine when not running headless. The response header contains the URL to redirect to, and a 302 status code is returned.
What would cause Chrome to behave differently when running in headless mode? Is there any logging that would help me to determine why the redirect isn't working as expected?
Edit: Found some more info. It looks like I'm unable to redirect to sites with bad certs. How can I deal with ERR_CERT_AUTHORITY_INVALID when running Chrome in headless mode?
I was having the same issue and as you pointed out it happens with sites that have bad certificates. Passing the --ignore-certificate-errors flag didn't work at the time of the original post as there was a bug.
Some options to pass to have chrome-headless send more debugging info:
--log-level=0 --enable-logging --v=1 bug tracker for chrome/chromium headless not accepting the --ignore-certificate-errors flag:
bugs.chromium.org/p/chromium/issues/detail?id=721739 – karlos Dec 7
'17 at 20:15
For anyone reading now the bug was patched recently here: https://chromium.googlesource.com/chromium/src.git/+/c8f0691b18dc5d941d5b6b3c67a483da02400670
And the --ignore-certificate-errors flag should allow redirects to occur when using headless chrome for sites with bad certificates.
as to date seems like --enable-features=NetworkService solves the issue of self signed certificated in headless mode
Related
I am starting a headless chrome instance like that, e.g.
/opt/google/chrome/chrome --headless --disable-gpu --remote-debugging-port=9222 https://www.chromestatus
and want to connect with DevTools to this instance by entering localhost:9222 into a running browser. However, what I see is just some garbled stuff like this here "��TQo�0~ϯ���$���li51����manri̜8�������m::�...", probably because the server process at localhost:9222 sends the response gzipped, but does not include a content-encoding in the response headers (at least, that's my theory why this happens...)
Any idea how I can fix this? I haven't found any option to control this behavior (e.g. to tell the headless chrome instance to not zip the response data...)
BTW: I see the same whether I enter the url in chrome, chromium or firefox or use wget, and also whether I use chrome (Google Chrome 84.0.4147.105) or chromium doesn't make a difference...
I am evaluating W3C pay Google examples by enabling the Chrome Extension from Google's example here: https://bobpay.xyz/ (Clicking "Install web payment app" on the bottom). This installs the W3C Pay Chrome extension.
I then use their demo here:
https://paymentrequest.show/demo/
I am able to submit a payment using the "Bobpay" extension, see below:
... however when it comes time to redirect to the Bob pay "Account Selector" web application (the front end of the Payment Handler), I get the following error in Chrome's Developer tools:
"Aborting payment handler window "https://bobpay.xyz/pay" because of navigation to an insecure url "chrome-extension://noojglkidnpfjbincgijbaiedldjfbhh/data/shared/tpc-check.html"
It's complaining that the redirection to the chrome-extension URL scheme is insecure.
I already took both Certs from bobpay.xyz and paymentrequest.show sites, and installed them to my System keychain. Then I trusted both SSL certs. This didn't help.
BTW, this works on Windows, but not on MacOS (Chrome on both).
Also: submitting a sample credit card payment outside of the Bobpay extension works fine (by using a locally stored Credit card option, and not the Bobpay extension) - returns tokenized card to be forwarded to payment processor.
This demo code also does not work on any other browsers, such as Firefox or Safari (unsupported on both).
In the Security panel of Chrome Developer tools, we can also see that the Chrome Extension for Bobpay is marked as "Unsecure":
I also installed the whole thing on Localhost, created a self signed SSL cert, added it to keychain, trusted it, and ran an https-server with that cert, but I get the same issue on https://localhost:8080/bobpay as well.
After verifying that the demo worked on another MacOS machine, I figured I introduced an issue trying to clone bobpay and deploy it on localhost under another name. The two payment handlers were somehow trampling over each other, when redirecting to the Frontend Handler page.
I ended up removing all Chrome files in ~/Library/Application Support/Google/Chrome, clearing all Chrome settings (reset to default), and re-installing Chrome. This cleaned out all extensions, cached data, and service workers under Dev Console --> Application. I am now able to proceed without errors.
JetBrains IntelliJ IDEA sometimes loses its own JetBrains IDE Support plugin in Chrome. Upon debugging in IDEA, Chrome complains that:
hmhgeddbohgjknpmjagkdomcpobmllji is blocked
Requests to the server have been blocked by an extension
and stays on this page:
chrome-extension://hmhgeddbohgjknpmjagkdomcpobmllji/loading.html?__QUERY__
Where hmhgeddbohgjknpmjagkdomcpobmllji is JetBrains' plugin ID.
Instead of redirecting to the target page of the form:
http://localhost:63342/__PROJECT__/__PATH__/index.html
Restarting Google Chrome or disabling-and-enabling IDE Support plugin helps. IDEA "finds" Chrome again and Debug workflow works as intended.
Another possible problem is a failed authorization.
To debug a URL like this:
http://localhost:63342/__PROJECT__/__PATH__/index.html
Open it in the browser before starting to debug. It'll give 404 Not Found. Then switch back to IDEA and it will offer you to Copy authorization URL to clipboard:
http://localhost:63342/__PROJECT__/__PATH__/index.html?_ijt=__KEY__
Open this URL.
After this manual authentication is complete, IntelliJ IDEA should be able to debug index.html in Chrome.
IDEA always opens index.html for debugging in the browser window where the latest authentication happened. E.g., in a Chrome Incognito window, instead of a Chrome "normal" window, if you've just authorized IDEA in Incognito.
Going incognito may require an additional setup:
https://intellij-support.jetbrains.com/hc/en-us/community/posts/206201319-launching-chrome-incognito-in-intellij-12
We have google chrome extension that needs to be used inside our organization. We have domains there.
Based on enterprise options the easiest approach for us is to host it on some internal web server, and then add address of that internal site as ExtensionInstallSources option to users PC via Group policies, but this does't work for me.
I've tried both registry and local Group Policy changes by adding Google Chrome adm\admx files.
Here is my registry change:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\ExtensionInstallSources]
"1"="http://localhost/*"
When i'm checking chrome://policy - it displays that it loaded this settings. But when i open http://localhost/myextension.crx - Chrome still displays an error that extension can't be installed from there...
I'm using 47.0.2526.106 m (64-bit) under Windows 8.1 Enterprise (x64)
What i'm doing wrong here?
I have more complicated option to download chrome source\pdbs, and then try to debug it to get understanding why it's not working but it may take a lot of time, as Chrome can compile for a couple of hours on Windows at first build....
So apparently this registry change just wasn't enough. After debugging chrome source i found why it doesn't work for me. I missed:
The referer MUST be present and it also should be whitelisted. So if i open url for my extension by direct link, then as referer is missing - it won't install it. (Oh Chrome, at least you could say with message about it...). If i have web page that has link to that extension, and it's also whitelisted, then it will work fine.
Second missed point was that extension id MUST be present in ExtensionInstallWhitelist, otherwise Chrome will install it and with 2-3 seconds delay will disable it. But if you have listed it under ExtensionInstallWhitelist, then it will be fine.
So my final registry change for localhost is:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\ExtensionInstallSources]
"1"="http://localhost/*"
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\ExtensionInstallWhitelist]
"1"="fhojekmcngnmkdbcoegjdlojgfngkpak"
I found it after long debugging in ExtensionManagement class - https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/extensions/extension_management.cc&q=ExtensionManagement::IsOffstoreInstallAllowed&sq=package:chromium&type=cs&l=148
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 4 years ago.
Improve this question
I'm getting this warning for visiting non https site as https
Tried this to disable it by adding that command to shortcut target, but it doesnt work.
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" -ignore-urlfetcher-cert-requests
Is there any possible method to disable ssl check for websites ?
To disable the errors windows related with certificates you can start Chrome from console and use this option: --ignore-certificate-errors.
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --ignore-certificate-errors
You should use it for testing purposes. A more complete list of options is here: http://peter.sh/experiments/chromium-command-line-switches/
Mac Users please execute the below command from terminal to disable the certificate warning.
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --ignore-certificate-errors --ignore-urlfetcher-cert-requests &> /dev/null
Note that this will also have Google Chrome mark all HTTPS sites as insecure in the URL bar.
In my case I was developing an ASP.Net MVC5 web app and the certificate errors on my local dev machine (IISExpress certificate) started becoming a practical concern once I started working with service workers. Chrome simply wouldn't register my service worker because of the certificate error.
I did, however, notice that during my automated Selenium browser tests, Chrome seem to just "ignore" all these kinds of problems (e.g. the warning page about an insecure site), so I asked myself the question: How is Selenium starting Chrome for running its tests, and might it also solve the service worker problem?
Using Process Explorer on Windows, I was able to find out the command-line arguments with which Selenium is starting Chrome:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-background-networking --disable-client-side-phishing-detection --disable-default-apps --disable-hang-monitor --disable-popup-blocking --disable-prompt-on-repost --disable-sync --disable-web-resources --enable-automation --enable-logging --force-fieldtrials=SiteIsolationExtensions/Control --ignore-certificate-errors --log-level=0 --metrics-recording-only --no-first-run --password-store=basic --remote-debugging-port=12207 --safebrowsing-disable-auto-update --test-type=webdriver --use-mock-keychain --user-data-dir="C:\Users\Sam\AppData\Local\Temp\some-non-existent-directory" data:,
There are a bunch of parameters here that I didn't end up doing necessity-testing for, but if I run Chrome this way, my service worker registers and works as expected.
The only one that does seem to make a difference is the --user-data-dir parameter, which to make things work can be set to a non-existent directory (things won't work if you don't provide the parameter).
Hope that helps someone else with a similar problem. I'm using Chrome 60.0.3112.90.