We are doing automation testing on a intranet application. Chrome browser does auto login when we visit the site (through NTLM login). We need to login as different users through automation test.
We were using the flag '--auth-scheme="digest"' to restrict Chrome from using NTLM.
args = ['--auth-schemes=digest']
Capybara::Selenium::Driver.new(app, browser: :chrome, args: args)
But looks like this option has been removed in Chrome v41. Related Issue
Is there any other way to achieve the same in new version of Chrome?
I found a way to restrict the AuthSchemes with help of registry. I will still look for a better way to do it.
AuthSchemes can be controlled by registry settings as per this link.
https://dev.chromium.org/administrators/policy-list-3#AuthSchemes
I created two files and running disable_chrome_ntlm_login.reg file restricts the AuthSchemes
1) disable_chrome_ntlm_login.reg
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"AuthSchemes"="basic,digest"
2) enable_chrome_ntlm_login.reg
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"AuthSchemes"="basic,digest,ntlm,negotiate"
Run "disable_chrome_ntlm_login.reg" file to disable NTLM authentication scheme before testing and "enable_chrome_ntlm_login.reg" revert the Chrome to old state.
Related
I am creating a website that have a link to download my chrome CRX app to install it on chrome, the problem is whenever I try to download it it's give me an error that says: " Package is invalid: 'CRX_REQUESTED_PROOF_MISSING' ".
How can I fix this problem?
NOTE: my app is working when I install it using developer tools.
My manifest.json:
{"name":"MY_APP_NAME",
"version":"0.0.1",
"manifest_version":2,
"minimum_chrome_version":"37.0.0.0",
"permissions":["webview","power","storage","videoCapture","geolocation","pointerLock","system.display",{"fileSystem":["write","retainEntries","directory"]},"accessibilityFeatures.read","accessibilityFeatures.modify"],"app":{"background":{"scripts":["js/foam.js","js/cab.js","config.js","background_main.js"]}},
"default_locale":"en",
"icons":{"128":"img/128.png"}}
I'm also currently having this issue and trying to find workarounds for it. Unfortunately it seems that due to Chrome's security policy, plugins needs to go through their webstore in order to have the multiple levels of "proof" before chrome will accept it as a legit extension. So far it seems the only way to get it to work is to load it as an unpacked extension, go through the webstore, or force install it via group policy.
Links and refs:
https://developer.chrome.com/apps/external_extensions
https://support.google.com/chrome/a/answer/6306504?hl=en
https://github.com/oncletom/crx/issues/109
According to documentation, Chrome does not allow installing CRX from outside of their store, unless in developer mode or through enterprise policy: https://developer.chrome.com/extensions/hosting_changes, or on Linux (it's mentioned at the beginning of linux_hosting i linked in my previous comment).
So that may be a reason, because in their source, that "proof missing" error is returned only if either public key is missing, or "required key" is missing:
https://github.com/chromium/chromium/blob/c48c9b176af94f7ec65e20f21594524526d2a830/components/crx_file/crx_verifier.cc#L178
"required key" seems to be their predefined key:
https://github.com/chromium/chromium/blob/c48c9b176af94f7ec65e20f21594524526d2a830/components/crx_file/crx_verifier.cc#L134
and
https://github.com/chromium/chromium/blob/c48c9b176af94f7ec65e20f21594524526d2a830/components/crx_file/crx_verifier.cc#L42
I'm guessing that's the public part of Chrome Web Store key? There's no easy or even "practical" way to create signature that will match their key.
So, either it's the missing Chrome Web Signature key, or something is wrong with how we create signature using developer's key.
How can I distribute my extension if I cannot upload it to the Chrome Web Store for policy reasons?
These changes are effective only on Windows stable and beta channel. Users who want to get extensions that are not hosted on the Chrome Web Store can do so on Chrome dev/canary channels in Windows or on all Chrome channels in other operating systems.
What are the supported deployment options for extensions after this change?
Apart from users installing extensions from the Chrome Web Store, the following deployment options will be supported:
For OSX and Linux, extensions can be installed via a preferences JSON file.
For Windows, extensions can be installed via the Windows registry. In the Windows registry, ensure that the update_url registry key points to the following URL: https://clients2.google.com/service/update2/crx. Local .crx installs via the path registry key are deprecated. Note that this deployment option works only for Chrome Web Store hosted extensions, and update_url cannot point to any other host other than https://clients2.google.com/service/update2/crx.
For Enterprises, we’ll continue to support group policy to install extensions, irrespective of where the extensions are hosted. Note that the user's machine has to join a domain for GPO policy pushes to be effective.
I've written an extension for Google Chrome that will be released with the next version of our product. I want to understand what properties, paths for extraction, registry entries, etc. should I provide the installer of my product so that the end user doesn't have to install the extension on their own manually, and the installer does the complete job of installing the extension, and also notifies the user that the extension has been installed. As of now, the code that I have written is placed in a folder, and I use the "Load Unpackaged Extension" to load the extension. What should I do to achieve the aforementioned task?
Google's current policy on installing extensions via the registry (for Windows machines) is this:
Only extensions from the Google Extension Gallery (or Chrome Web Store - CWS) can be installed via the registry.
See this link - https://developer.chrome.com/extensions/external_extensions - for information on how this can be done. Keep in mind the following:
-This technique will still pop-up a msgbox to the user. its not completely silent.
-When using this technique, if the user subsequently removes the extension from her Chrome, the extension gets "blacklisted" on that chrome and will not re-auto-install until the user re-install it
manually. refer to Auto-installing a google chrome extension won't work ! for details.
Chrome has a couple ways of installing extensions programmatically:
http://www.chromium.org/administrators/pre-installed-extensions
Edit: yes, this policy has changed by now, as FuzzyAmi points out.
If you're using GNU/Linux, this is how you pre-install an extension from the chrome web store for all users:
/etc/chromium/policies/managed/yourextension_policy.json
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
{
"ExtensionInstallForcelist": [
"yourextensionuniqueidentifiersup;https://clients2.google.com/service/update2/crx",
"yourextensionuniqueidentifiersup"
]
}
Reference
metamask-chrome - AUR
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
I've written an extension for Google Chrome that will be released with the next version of our product. I want to understand what properties, paths for extraction, registry entries, etc. should I provide the installer of my product so that the end user doesn't have to install the extension on their own manually, and the installer does the complete job of installing the extension, and also notifies the user that the extension has been installed. As of now, the code that I have written is placed in a folder, and I use the "Load Unpackaged Extension" to load the extension. What should I do to achieve the aforementioned task?
Google's current policy on installing extensions via the registry (for Windows machines) is this:
Only extensions from the Google Extension Gallery (or Chrome Web Store - CWS) can be installed via the registry.
See this link - https://developer.chrome.com/extensions/external_extensions - for information on how this can be done. Keep in mind the following:
-This technique will still pop-up a msgbox to the user. its not completely silent.
-When using this technique, if the user subsequently removes the extension from her Chrome, the extension gets "blacklisted" on that chrome and will not re-auto-install until the user re-install it
manually. refer to Auto-installing a google chrome extension won't work ! for details.
Chrome has a couple ways of installing extensions programmatically:
http://www.chromium.org/administrators/pre-installed-extensions
Edit: yes, this policy has changed by now, as FuzzyAmi points out.
If you're using GNU/Linux, this is how you pre-install an extension from the chrome web store for all users:
/etc/chromium/policies/managed/yourextension_policy.json
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
{
"ExtensionInstallForcelist": [
"yourextensionuniqueidentifiersup;https://clients2.google.com/service/update2/crx",
"yourextensionuniqueidentifiersup"
]
}
Reference
metamask-chrome - AUR
so, have web-site configured for ADFS 2.0 authentication...
for IE - it works fine and did authentication correct
for Chrome - it reaches redirect to AD FS server... ask to authenticate but could not authenticate.
I try to requests using fiddler but it show nothing interesting - so show that we redirect to adfs for authentication but nothing more
what it could be? why it is impossible to authenticate for chrome
thanks
In the event viewer you will see an 'Audit Failure' event with "Status: 0xc000035b". You can circumvent this problem by switching off 'Extended Protection' for the adfs/ls web application.
There are several articles on the Web on this, for example the "0xc000035b error during windows integrated login" thread on Microsoft's AD FS forum. Quoting:
To turn Extended Protection off, on
the AD FS server, launch IIS Manager,
then, on the left side tree view,
access Sites -> Default Web Site ->
adfs -> ls. Once you’ve selected the
"/adfs/ls" folder, double-click the
Authentication icon, then right-click
Windows Authentication and select
Advanced Settings… On the Advanced
Settings dialog, choose Off for
Extended Protection.
This issue occurs in several situations that I know of: when using Firefox 3.5+ or Chrome, using some specific NTLM configuration for which I don't have the details at hand, and when using Fiddler (see the "AD FS 2.0: Continuously Prompted for Credentials While Using Fiddler Web Debugger" TechNet article post, and the "Fiddler and Channel-Binding-Tokens" blog post which contains more technical background information).
(Note that nowhere I could find any information how to make NTLM authentication to AD FS from, e.g., Google Chrome and Firefox 3.5+ work without switching off 'Extended Protection'. I mean, Internet Explorer works with 'Extended Protection', why don't Chrome or Firefox? Or is this a Chrome/Firefox implementation bug/restriction, e.g., in their use of the Windows NTLM library?)
From Microsoft: http://technet.microsoft.com/en-us/library/hh852537.aspx
Unless and until Firefox, Google Chrome, and Safari support Extended
Protection for Authentication, the recommended option is to install
and use Internet Explorer 10 or later. If you want to use single
sign-on for Office 365 with Firefox, Google Chrome, or Safari, there
are two other solutions:
(1) Uninstall the Extended Protection patches
from your computer. (2) Change the Extended Protection setting on the
Active Directory Federation Services 2.0 server. See
“ExtendedProtectionTokenCheck” on the TechNet Set-ADFSProperties page
for details.
Switching off extended protection is not the answer. You add chrome as so adfs can recognize it and then add the site to the trusted list.
Make sure chrome is supported by adfs.
So, if you run the following commands:
$a=Get-Adfsproperties
$a.WIASupportedUserAgents
Then you add chrome to the list.
Set-ADFSProperties -WIASupportedUserAgents #("MSIE 6.0", "MSIE 7.0", "MSIE 8.0", "MSIE 9.0", "MSIE 10.0", "Trident/7.0", "MSIPC", "Windows Rights Management Client", "Mozilla/5.0")
Now, we will need to tell the Chrome that it should allow Windows Integrated Auth for the site.
To do this, you will need to go to the settings:
Click on Advanced
Click on Proxy settings
It should open your IE Properties. Click on Security & Select "Local Intranet" and add the Federation service name of your ADFS here.
Click close and Apply under IE Properties.
Restart Chrome and next time when you try to access the site, it won't ask you for credentials.
This was a solution presented at work to allow SSO with Chrome WITHOUT disabling Extended Protection. Cheers for MS support.