With Chrome Version 27.0.1448.0 dev while attempting to call
chrome.downloads.download(url:song.url);
I receive the error chrome.downloads is not available: You do not have permission to access this API. Ensure that the required permission or manifest property is included in your manifest.json.
My permissions look like.
"permissions": [
"downloads",
"https://*/*", "http://*/*",
"tabs"
],
I believe that this is an experimental feature, so you may need to request "experimental" permission as well.
Related
I am trying to get U2F to work under Chrome. I'm developing so I'd like it if I could connect to my local web server with not HTTPS certificate.
I am running Chrome in OSX
Currently my workflow is
Quit all instances of Google Chrome.
Restart Google Chrome with the --show-component-extension-options command-line flag.
Navigate to chrome://extensions and enable Developer Mode by clicking a checkbox in the top right corner.
Find the CryptoTokenExtension extension.
Click on "background page". This will open a Developer Tools window, including a Console.
In the console, type:
HTTP_ORIGINS_ALLOWED = true;
and it still doesn't work. What step am I missing
Just changing the value won't reregister the extension's manifest.json which has to be patched too:
"externally_connectable": {
"matches": [
"https://*/*"
],
You can manually edit resourse.pak file in any binary/hex editor (not a text editor).
In Windows it's usually in %LocalAppData%\Google\Chrome\Application\xxxxx\resources.pak
Backup the file
Find "fjajfjhkeibgmiggdfehjplbhmfkialk"
Replace the nearby "https://*/*" with "*://*/*"
Optionally edit HTTP_ORIGINS_ALLOWED
Save and restart Chrome
You can automate this by writing a simple patcher in node.js or any other scripting language.
P.S. Not tested.
Is there any way we can launch the chrome window with all the extensions installed on chrome?
{
"version": "0.2.0",
"configurations": [{
"type": "chrome",
"request": "launch",
"name": "Launch Chrome against localhost",
"url": "http://site.example.com/",
"webRoot": "${workspaceFolder}"
}]
}
Setting the userDataDir property in the launch config to false will allow you to launch Chrome using your personal user profile. However, I would suggest keeping your debugging environment sandboxed and separated from your personal profile instead.
By default, Chrome debugger will create a new profile for your debugging session and will persist until you restart your computer. The profile directory will be in your %TEMP% folder. The trick here is to create a profile just for your workspace. You could then configure this profile to have whatever extensions and other settings that you need. We just need to make it persist permanently by specifying a different location.
Instead, set the userDataDir property to a path in your .vscode directory (and ignore in your source control). It will create the profile in that directory you set. I use:
${workspaceFolder}/.vscode/vscode-chrome-debug-userdatadir
Then when you run the debugger, it will create a profile in that directory that should persist indefinitely. You could then install all the extensions you want, all without muddying up your personal profile.
If you want a central debugging workspace to be used for multiple projects, you could put it in your home folder (or other location) rather than your project workspace.
${env:HOME}/.vscode/vscode-chrome-debug-userdatadir
One way is to prevent the debugger from starting a chrome instance with a seperate profile.
Just add "userDataDir": false within "configurations" to your launch.json.
Close all Chrome instances, than start debugging from Visual Studio Code.
Your previous chrome session should open including a new Tab serving your files.
Afterwards you can start/stop debugging without closing and reopening chrome.
Source: https://marketplace.visualstudio.com/items?itemName=msjsdiag.debugger-for-chrome
I'm thinking of moving some of the permissions in an unpublished Chrome extension to being optional instead of required in the manifest, and wanted to test the user flow.
Calling chrome.permissions.request() in an unpacked extension seems to just succeed silently. The browser dialog that the user should see isn't displayed.
This Chrome developer page suggests you can test the normal user flow using a packaged .crx file:
If you'd like to see exactly which warnings your users will get, package your extension into a .crx file, and install it.
However, Chrome no longer seems to let you install an arbitrary .crx file outside of the Chrome Webstore. Dragging and dropping the file on the Extensions page lists it, but the Enabled checkbox is disabled. This SO comment indicates that testing permissions in this way is likely no longer possible, but I haven't seen any official documentation about it.
I was actually able to install and enable a non-Webstore .crx file by adding it to the extension whitelist in the Windows registry, using these instructions, but that extension didn't trigger the permission request dialogs either.
So my questions are:
Is there a way to test the permission request flow other than publishing an extension to the Chrome Webstore?
What's the best way to remove the optional permissions once you've accepted them, in order to test the flow again? Delete the extension? Call chrome.permissions.remove()?
Turns out I confused myself by requesting the "sessions" permission when the extension already had a required "tabs" permission. Apparently, requesting "sessions" when you already have "tabs" doesn't trigger the permissions dialog.
However, calling something like chrome.permissions.request({ permissions: ["bookmarks"] }) does, in fact, show the permissions dialog, even in an unpacked extension.
So the answers are:
There's no need to publish an extension to the Chrome Webstore. Just request an optional permission with your local unpacked extension to see the dialog.
It looks like the only way to trigger the permissions dialog again is to delete the extension completely and reinstall it. Calling chrome.permissions.remove() does remove it as far as the APIs go, but the permission is silently re-added if it's requested again.
I have a chrome extension (.crx) that when I install it directly everything works fine, but doesn't when I try to load it in developer mode with the manifest.json I created.
I no longer have access to the developer who wrote this extension for me, so I tried to package it for the Chrome store myself.
To explain in more detail. The usecase where my chrome extension works:
I open the extensions area in Chrome
I drag and drop the .crx file into my chrome extensions dashboard
My icon appears as expected in the toolbar
I click on the icon and the dialog box for my extension appears as expected
The usecase where my packaged chrome extension doesn't work (after uninstalling the .crx file):
I created a package, with the manifest.json described below incorporating the exact same .crx file used successfully above.
To test the package, I went to the extensions dashboard, made sure my "Developer Mode" checkbox was enabled, and selected the "Load Unpacked Extension".
No errors, and the icon loads just fine.
I click on the icon in the browser toolbar, nothing happens! No dialog appears even though it is the exact same .crx file.
Here's the manifest.json I created:
{
"manifest_version": 2,
"name": "Rock the Deadline Curation Extension",
"version": "5.2",
"description": "This extension allows you to bookmark and curate content into RTD Studios and share with other studio users.",
"icons": {"128": "RTD-Square-Icon_128x128.png"},
"browser_action": {
"default_icon": {
"19": "discover-iconx19.png",
"38": "discover-iconx38.png"
},
"default_title": "RTD Studios"
}
}
Any thoughts? Thanks so much in advance!
Reverse engineering an extension could be a complicated process, and I wouldn't recommend it if you don't need to. But a .crx file is a .zip file with some extra stuff at the beginning. This means that you may be able to unzip the file as if it were a .zip file, and ignore any error that comes up. I've not been able to do this with Windows right click "Extract All", but I have done this with the Mac OS X unzip command. Once you have the extracted folder, you can load the extension using your second step 2 above.
UPDATE: Solved one part, but not other
I have the CRX updating now (it was not rebuilding).
However, Chrome will not accept the XML or CRX at an https URL.
I believe #2 is because it's a self-signed certificate. Does anyone know if there's a way around this? (This is purely for development, so hosted internally)
ORIGINAL POST:
I created a packaged extension that is hosted on my internal website, but is added to Chrome via dragging it from the desktop (because Chrome won't allow installing packaged extensions via external websites - see here: After adding ExtensionInstallSources preference with my URL to Chrome Preferences, still won't allow installing ".crx" packaged app ).
The manifest has the update_url set to an XML file located on my site. That XML file has the url for the crx file set under updatecheck codebase='...'. Both files exist on the website and are findable. I also upated the version number from 2.0.0.2 to 2.0.0.2 in both the XML file and the manifest.json. I also made a change in the index.html file of the extension.
I checked the appid and it is the same in the XML file and in Chrome.
Despite clicking the "update extensions now" button about 50 times, and waiting 10 minutes, it does not update.
NOTE: I did alias the internal ip 192.168.1.108 where the site is hosted in my hosts file as myinternal.fake but this works in both chrome and firefox so I don't think that's the issue
Update XML File (located at: https://myinternal.fake/updates/helloworld.xml)
<?xml version='1.0' encoding='UTF-8'?>
<gupdate xmlns='http://www.google.com/update2/response' protocol='2.0'>
<app appid='akchdaojnpiglpjeiamjpacbkppcgbgj'>
<updatecheck codebase='https://myinternal.fake/helloworld.crx' version='2.0.0.2' prodversionmin='23' />
</app>
</gupdate>
manifest.json
{
"manifest_version": 2,
"name": "Hello World",
"version": "2.0.0.2",
"minimum_chrome_version": "23",
"update_url": "https://myinternal.fake/updates/helloworld.xml",
"icons":
{
"16": "icon_16.png",
"128": "icon_128.png"
},
"app":
{
"background":
{
"scripts":
[
"main.js"
]
}
}
}
EDIT: I also checked and the header is an acceptable one for Chrome (according to this: http://developer.chrome.com/dev/extensions/hosting.html). It sends the CRX file as "text/plain" and does NOT send the header X-Content-Type-Options: nosniff so it should be valid.
Also, when I changed from https to http, now when I click "update extensions now" the extension disappears for a split second which indicates it's now reading the XML, but still not accepting the update!
The issue is with self-signed certificates and Chrome. Chrome does not accept Extension updates form self-signed certificates unless they're an "accepted" authority. These steps will make it work:
Follow these steps: https://stackoverflow.com/a/15076602/857025 to export your certificate and then import it as an authority
Close Chrome
Restart Chrome
Close extensions window if opened
Reopen via "chrome://extensions" and then click "update extensions now"
It should then update your extension located on a self-signed https connection.
UPDATE This is not a perfect solution as Chrome appears to be a bit wonky in accepting self-signed certs. It randomly stops seeing updates. If I switch back to using regular http (for the update_url and the CRX's url), updates happen every time.
I checked and my cert is still a trusted authority but Chrome suddenly stopped recognizing updates, so there must be an issue with this.
By the way Google Stopped supporting updating extensions that are hosted outside of Chrome Webstore: http://blog.chromium.org/2013/11/protecting-windows-users-from-malicious.html