My code is like this, but can't intercept requests from other extensions (e.g. Postman):
chrome.webRequest.onBeforeRequest.addListener(
function(details){
console.log(details.method + " ====== "+ details.url + " ====== " + details.timeStamp);
console.log("---requestbody----: " + details.requestBody);
},
{urls: ["<all_urls>"]},
["blocking"]
);
Indeed, this code won't.
This is a security feature: webRequest cannot intercept any requests from other extensions or Chrome Apps. Otherwise, it would be possible to inject your code if another extension was loading a third-party library.
It used to be able to, but it was deemed a security bug and fixed.
There is no way to override this.
Generally, extensions are not allowed to interfere with each other (except for external messaging, but both parties have to actively participate) because of privilege escalation concerns.
You cannot intercept other extension requests but what you can do is get and then change the extension that you want to intercept and add external messaging between those two extensions.
Getting the source and modifying it
Install the Chrome extension source viewer.
Go to the page in the Chrome Web Store of the extension you want to modify.
Click on the yellow CRX button, and choose Download (screenshot).
Extract the zip file.
Read the source code, and change what needs to be changed (in your particular case, I had quickly identified that you wanted to change edit config.js and change the "channel" property). Save the changes.
Or
Copy the folder of the extension you wish to modify. ( Named according to the extension ID, to find the ID of the extension, go to chrome://extensions/). Once copied, you have to remove the _metadata folder.
Using the modified version of the extension.
Visit the Chrome extension page (chrome://extensions/).
Enable Developer mode, by putting a check on the checkbox in the upper-right corner.
Click on the "Load unpacked extension" button.
Select the folder of your extension (to know which folder is correct, check whether the folder contains a file called manifest.json).
Confirm. You're done.
Unless you've made a mistake in either of these steps (including the modification of the source code), the modified extension should work as intended.
Source: How to modify an extension from the Chrome Web Store?
Related
I am planning to develop a google chrome extension which will help with a home brew functional testing framework. Here's the puzzle:
There is no predefined url pattern where test pages could reside.
I don't want the extension to get invoked by a match-all url pattern and then decide the page is of no interest.
What I want instead is for the extension to be completely dormant and to be able to invoke it from within the test pages.
Is this possible? If so,
What should I have in my manifest?
How do I implement the wake-up call in my test page javascript?
Could the call be made whilst I am developing the extension, before it gets an id?
Edit:
This answer shows how a page could call an extension, but it needs an extension ID. Is there a way to get a temporary extension ID before the extension is published?
This is the first option I was thinking of but you do have to specify a second-level domain in the URL pattern.
Add this to your manifest.json
"externally_connectable": {
"matches": ["://.example.com/*"]
}
As such: *://*.example.com/*
not *://*.com
More information about chrome extension message passing here:
https://developer.chrome.com/extensions/messaging#external-webpage
You will need to specify an id for the communication. You can get your extensions id by visiting chrome://extensions
Not knowing your stack or build process I would set up a separate dev and prod config file with my dev and prod id's in the respective files. This will help avoid pointing to your development extension when you release your app to production.
An alternate option would be to inject on each page and invoke your script depending on the pages content.
There are gazillions of tutorials on how to convert a bookmarklet (or any javascript) to a Chrome extension, but I need the vise versa procedure. I have some extensions, which I would like to have as bookmarklets. The idea behind this: I don't want these extensions as they constantly eat away my RAM. Instead, I want simply press a button and run a bookmarklet, if I need it.
An example is this extension, which simply toggles javascript on/off in the browser. This extension contains only one javascript file (not including icons, manifest.json, and signature file _metadata/verified_contents.json).
I tried to use this javascript as a bookmarklet, but doing so doesn't conduce me to success - javascript wasn't toggled. It seems, that I'm missing something substantial, but I don't know what. Could somebody point me to the right procedure of conversion Chrome extensions to bookmarklets?
Conversion to a bookmarklet is impossible for extensions that use privileged chrome API available only for Chrome apps and extensions, in this case chrome.contentSettings.javascript.set.
The root cause - memory hogging by an extension - can be resolved by switching from a persistent background page to an event page that is unloaded when an extension is not used.
You may nag the author of that extension to do so.
Unfortunately, most of the extension authors appear to be unaware.
Another possibility is to edit the extension's manifest.json manually by adding "persistent": false as shown in the event page docs (don't forget the comma), then load it locally. Some extensions will fail since switching to an event page may require reworking of code.
I'm making an extension that among other things edit a javascript file in an external editor (one on the user's computer). The extension has the javascript file saved in chrome.storage but it will ofcourse be a lot easier for the user to write code in their own editor.
This is why I decided to find something that creates a file on the user's filesystem which the user can find and edit it themselves, and if any changes are made, sync that back up to the extension (either by periodically checking or by using some listener).
I have looked around but nothing really seems to fit what I'm trying to do. Chrome's fileSystem API only works for chrome apps, not chrome extensions and the HTML5 fileSystem API does not allow for a simple filesystem URL to be requested and opened, instead it obfuscates the stored file and makes it practically impossible to edit that file easily.
Something else I looked at which might be more promising is letting the user edit one of the files in the directory where the extension is stored and somehow retrieving that content. This is however going to be a bit tough to implement with chrome's all the hash checking going on in chrome extensions not to mention the general modifying of those files' contents by the extension (possibly by hacking around by specifying your own update URL and "updating" a dummy javascript file that is going to be written to).
Is there any way to simply ask for a location to store a file and then allow the user to edit that file and sync it back up?
No, extensions are sandboxed from the real filesystem.
As you said, it's possible to read extension's own files; however, this is read-only for the extension and modifying those files on a deployed extension will result in Chrome detecting extension "tampering" and immediate disabling as a precaution.
The only way for a Chrome extension to escape the sandbox is, as wOxxOm suggested, a Native Host module. Note that this cannot be distributed in Chrome Web Store with the extension; it needs a separate installer.
Alternatively, you could use some sort of cloud storage with API to access it; e.g. a user could store something in a Dropbox subfolder, and your extension can authorize access to it via Dropbox API. Unfortunately, there is no "native" solution like syncFileSystem for Apps.
Is it possible to modify the JavaScript of a page and then reload the page without reloading the modified JavaScript file (and thus losing modifications)?
This is a bit of a work around, but one way you can achieve this is by adding a breakpoint at the start of the javascript file or block you want to manipulate.
Then when you reload, the debugger will pause on that breakpoint, and you can make any changes you want to the source, save the file and then run the debugger through the modified code.
But as everyone has said, next reload the changes will be gone - at least it lets you run some slightly modified JS client side.
Great news, the fix is coming in March 2018, see this link: https://developers.google.com/web/updates/2018/01/devtools
"Local Overrides let you make changes in DevTools, and keep those changes across page loads. Previously, any changes that you made in DevTools would be lost when you reloaded the page. Local Overrides work for most file types
How it works:
You specify a directory where DevTools should save changes. When you
make changes in DevTools, DevTools saves a copy of the modified file
to your directory.
When you reload the page, DevTools serves the
local, modified file, rather than the network resource.
To set up Local Overrides:
Open the Sources panel.
Open the Overrides tab.
Click Setup Overrides.
Select which directory you want to save your changes to.
At the top of your viewport, click Allow to give DevTools read and write access to the directory.
Make your changes."
UPDATE (March 19, 2018): It's live, detailed explanations here: https://developers.google.com/web/updates/2018/01/devtools#overrides
The Resource Override extension allows you to do exactly that:
create a file rule for the url you want to replace
edit the js/css/etc in the extension
reload as often as you want :)
In the devtools preferences check the Enable local overrides.
Go to network tab, find the file you want to edit, rigth click on it and select Save for overrides (on the sources/overrides tab you need to add a local folder)
The file appears in a new tab on the Sources tab as local copy, so you can edit this file, and after site reload the new (and edited) override file will load on the site!
I know it's not the asnwer to the precise question (Chrome Developer Tools) but I'm using this workaround with success: http://www.telerik.com/fiddler
(pretty sure some of the web devs already know about this tool)
Save the file locally
Edit as required
Profit!
Full docs: http://docs.telerik.com/fiddler/KnowledgeBase/AutoResponder
PS. I would rather have it implemented in Chrome as a flag preserve after reload, cannot do this now, forums and discussion groups blocked on corporate network :)
Yes you can eazily!
Source -> filesystem -> choose the conatainer folder -> allow access -> open your file, edit and save.
https://www.delftstack.com/howto/javascript/edit-javascript-in-the-browser/
I started to work on a very cool Chrome extension and I ran into a little problem.
I want to allow my user to share a link. By sharing this link, other users can get some information with my extension.
The problem is when a user click on the shared link, I want to check if my Chrome extension is installed on his browser. If it does - great, else - I want to redirect him to download my extension.
Any ideas how to?
One possibility is to have your extension run a content script on all sites* and add a listener for click events on document. It would check event.target to make sure it's a link and has a particular prefix, and if it does, it would call the preventDefault method of its parameter and do its stuff. For users without your extension, the link would of course work like any other.
*This causes Chrome to warn your potential users about this when they install your extension; read Permission Warnings for more information.
Make the extension add an invisible element to the DOM of every page that it loads, marking it with a unique ID. When the user clicks on that link, run some javascript to check for that element -- if it doesn't exist, then you know the extension hasn't been installed.
I think you should be able to set/modify headers in the HTTP requests (as of Chrome 17?). Adding a header to requests would mean you can detect the presence of the extension on the server side.
This is fairly unintrusive. Many extensions/plugins have historically modified the User-Agent header.