Is there a way to copy an extension from a browser to another browser (both chromium based)?
In windows 10 I know the browser reads its data from this folder:
C:\Users<account_name\AppData\Local<browser>\User Data\Default
in Default there are several folders, among many:
"Extensions" and "Local Extension Settings"
which have as many folders inside as there are extensions installed and each of these folders has the extension id as its name.
So I tried copying Extensions\<id_ext> and "Local Extension Settings"\<id_ext> to their respective folders of another browser, but that wasn't enough.
Do I forget something (some other folder and\or registry key) or i's not possible to do this operation (without breaking the browser of course)?
EDIT
my goal is to have an old version of an extension fully installed in the browser (make the browser believe that it comes from the CWS) but in which I have disabled future updates (by modifying the update_url field in the manifest.json file with a fictitious address)
EDIT # 2
I will try to add two lines to better explain my purposes.
I've read something on SO and beyond, but nothing that can enlighten me about it.
My aim is to install an old version of an extension created by me
(I have the extension public key but I no longer have the private key), to block the update for a certain time and then update when I want by resetting the update_url field in the manifest.
Thanks
Related
I am trying to show and configure Quick Launch toolbar on Win 10 taskbar from command line / batch file / registry patch / PowerShell script / VBS / C# / C++. After searching the Internet, I was able to accomplish two steps out of three:
Pre-fill the "%USERPROFILE%\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch" folder with the .lnk files that I want to appear in the Quick Launch toolbar - this is easy.
Force the Quick Launch to show on the taskbar by adding a specific blob into HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Streams\Desktop key, TaskbarWinXP value and restarting Explorer so that the changes take effect. The format of the blob is not documented, but this is of no concern to me - I simply need to ensure that the taskbar contains only Quick Launch toolbar and no other toolbars, so I can afford to just prepare the taskbar on a test machine, export the blob and then import it into the registry on target machine. And the Quick Launch toolbar does show up on the taskbar and shows all the links corresponding to .lnk files. Not the most elegant way, but it works.
Update 0: actually it does not really work - the account name is hard-coded in the blob as part of the path to the Quick Launch folder, so when moving from a test machine to the target machine the blob will not work if the username is different of the target machine. I guess I will need to reverse-engineer the blob format anyway in order to generate a correct one.
But, and this is where I am stuck, the Quick Launch toolbar needs further configuration programmatically, specifically:
Hide the toolbar title
Hide individual text for the link icons
Move the toolbar all the way to the left so that it is next to the Start button
I can't find any recipes for that.
These settings are not stored in the HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Streams\Desktop key, TaskbarWinXP value blob, I did binary comparisons of different versions of this blob before and after manual change, they are identical. They must be stored somewhere else.
Update 1: I was wrong, these values are stored in the blob, but they are not committed to the registry right away by Windows Explorer. It seems like Explorer holds these values in RAM and only commits them to registry when it terminates normally, e.g. during logout or reboot. If you terminate Explorer by killtask, it won't commit these changes.
I also tried spying on the system using SysInternals procmon64 while I perform these three actions manually with a mouse. Process monitor does not detect any meaningful and relevant activities with either registry or files during such manual manipulations, only a bunch of background noise. But Explorer has to store these changing settings somewhere... What am I missing?
Update 2: As I have mentioned in the update 1, the reason I don't see any registry traffic when I am manually creating the toolbar is because Explorer postpones registry commit until normal shutdown.
So, after all updates, I have quite opposite situation: I no longer have issues with item 3, but I do need to know the format of the blob stored in registry HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Streams\Desktop key, TaskbarWinXP value. Or a proper API to create such blob. Anyone has any pointers?
OK, I have solved my problems. And I did not have to reverse-engineer the blob format for that (although I have started that fun process and managed to learn a few things about its internal structure). Anyway, my solution was this:
On a clean test machine manually create a Quick Launch toolbar using the mouse, but, when asked to specify the path to the toolbar folder, instead of navigating step-by-step to C:\Users\<insert_your_fixed_username_here>\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch, which would commit a fixed username into the blob as part of the path, you need to specify "%USERPROFILE%\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch" in Select Folder dialog as one line (the starting location for the Select Folder dialog is not important in this case). When you do that, Explorer will create a blob where the current user name is not hard-coded, and instead the environment variable %USERPROFILE% name is placed in the blob. This makes the blob re-usable for any user I want to deploy the Quick Launch toolbar to.
Adjust the Quick Launch the way you desire (title, text, position, width, icon order).
Log out from your account on test machine and log right back in. This is critically important - if you do not log out or if you kill Explorer, it will not commit your new toolbar settings to the registry.
Export HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Streams\Desktop key from the registry into the .reg file for future use.
The rest is easy, write a batch file that does the following:
For each given user on the target machine prepares the "C:\Users\<insert_your_fixed_username_here>\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch" folder and places necessary .lnk files there and deletes unnecessary ones.
Imports .reg file into the target machine registry (reg import command).
Kills and restarts Explorer: taskkill /f /IM explorer.exe & start explorer.exe
Now any desired user on your target machine will have exactly one Quick Launch toolbar and no other nonsense toolbars! And the toolbar will have the look and feel you want.
Tested on both real and virtual machines, works equally well.
Caveat: did not test on non-English version of Win10, and I expect localization issues because some folder names are hard-coded now.
I've got a Visual Studio installer project (a vdproj) that won't install the VC redistributables as a pre-requisite. I can't figure out why.
I'm using the latest updates to Visual Studio 2019, with the Installer Projects extension. Here are my prerequisite settings:
At install time I get an error that says vc_redist.x64.exe has changed since it was initially published. I checked bootstrap at C:\Program Files (x86)\Microsoft SDKs\ClickOnce Bootstrapper\Packages\vcredist_x64 and discovered that the URL found there (https://aka.ms/vs/16/release/14.26.55555/vc_redist.x64.exe) redirects to the main microsoft home page and downloads HTML rather than an executable. So I changed the URL, first to https://aka.ms/vs/16/release/vc_redist.x64.exe, then to https://aka.ms/vs/16/release/14.27.29016/vc_redist.x64.exe. Both of these URLs download a copy of VC_redist.x64.exe when you visit them with a web browser, but neither of them fixes the installer.
The only difference I see after changing the URL is that with the original URL I get a file named vcredist_x64\vc_redist.x64.exe in the temp install folder (but it's invalid, full of HTML), but with the two new URLs the vcredist_x64 folder is empty.
Any idea what I need to do to get this working?
I found the solution. I needed change the URL and the public key. Here are the steps you would follow to resolve an issue like this in the future:
Find the URL to a version that is still available. The latest version is currently available from here: https://aka.ms/vs/16/release/vc_redist.x64.exe. The version-specific URL to that same file is currently http://aka.ms/vs/16/release/14.27.29016/vc_redist.x64.exe.
Note the version number. If you don't already know it, you can get it by simply hovering over the downloaded file in file explorer.
Find the public key. I learned how to do that from an answer in this question. You find the key by right-clicking on vc_redist.x64.exe, selecting properties, Digital Signatures, then double-click on the sha1 entry. Click View Certificate, then Details, then Public key. Copy the value that shows up in the text box.
Remove all the spaces from the public key you copied. The public key for v14.27.29016 of vc_redist.x64.exe is:
3082010a02820101009208daf213e09ec32da6e2dfdaef8c19ec2f584f0bf53f20b806f33f91258f36cf27d114def85bd87d4f84f6e7f4b7b9d8940cc78cafa99627f60610fe36076121443cb15c163b7f6d8ef4111e33f6fffbd2bc87e69a446830bd488678ecf64422650cd8443618469f71490626470423939865f3f53b4603a24038ad547694ec14f5308f7695f651b882030d805dbd7b5b7256093153b0a99b6fd0ef73402adeb7a47e7d148668335f104a5c20b2fe0fb455dcce2e6891384dae8a00e76f57e315689a7561715364f2ada631cee9df691d03d9886ecd742e906e74469ac6b8f2e350adbe807e62ca0c8d4ba77d56328813697e6d65ff82653f4f4aebe33822cd0203010001
Open C:\Program Files (x86)\Microsoft SDKs\ClickOnce Bootstrapper\Packages\vcredist_x64\product.xml in a text editor, as administrator.
Replace the value of the PublicKey with the key you prepared in step 4.
In the BypassIf element, replace the Value with the version you noted in step 2. Save and close the file.
Open C:\Program Files (x86)\Microsoft SDKs\ClickOnce Bootstrapper\Packages\vcredist_x64\en\package.xml in a text editor, as admin.
Replace VCRedistExe with the URL from step 1. You can use either the generic or the version-specific URL. They both have drawbacks. Save and close the file.
Rebuild your installer.
You may need to make adjustments for your environment.
Regarding the choice of URL, I suspect neither will work forever. If you use a version-specific URL, that version might go away (which is the whole reason we're needing to mess with this in the first place). If you use the version-agnostic URL, then when a new version comes out the product key probably won't match.
It's really unfortunate that Microsoft makes existing installers break by taking old redist packages down, and doesn't provide the updates required for new installers to work out of the box.
Ok, I have never seen anything like this before and hoping someone else has. I just finished patching our Dev and Test servers to Nov2017CU (SharePoint 2013). Since then, any solutions that are using JS injection from Site Assets are not updating. I'll make a change to the file, the library reflects that I made the change, but when I attempt to load the page accessing the js file, the changes are not reflected. Hard refreshes and full cache cleans are not affecting it. If I close and reopen my editor (VSCode) my changes are gone. When I look at the version history, the current version doesn't have my changes, but the previous version does. If I try to revert to that version, it doesn't take (still shows the previous version of the file).
Here's where it becomes extra weird. I have deleted the entire file from the library. Reset IIS (heck, I even rebooted the server at one time). It somehow still loads the file. The file is no longer in the library, but the server is still serving it up to the browser. I have confirmed it is not getting it from another location as the Dev tools are showing the file is located in the Asset Library the file was deleted from. Even users who have never accessed the site before are still getting that file in their browser.
This isn't limited to a single site either. I have other developers in different sub sites (same site collection) that are having the same issues.
Anyone seen this before?
Looks like your web application has BLOB cache enabled which is causing files to served from the cache.
There are 2 ways to fix:
1) The heavy handed way would be to flush the BLOB cache using powershell commands mentioned:
$webApp = Get-SPWebApplication "<WebApplicationURL>"
[Microsoft.SharePoint.Publishing.PublishingCache]::FlushBlobCache($webApp)
This will flush all the files in the BLOB. Usually, the files are cached based on the max-age attribute value. So, that is the reason that your files are being served even if you had deleted it from the source.
2) The surgical knife approach would be to append a query string, like (https://sitecollurl/siteassets/app.js?v=1.1), to the file references (usually in master page, page layouts, webpart references, script links etc. wherever it is referenced). When you append a query string to the file, it will force the browser to download the newer version of the file. Would prefer this approach as it will not unnecessarily clear other files from BLOB.
I have a Windows system that is a part of a domain. I've imported the domain GPO chrome .admx file and then created the Chrome GPO policy for 'ExtensionInstallForceList' property by using http://dev.chromium.org/administrators/policy-list-3#ExtensionInstallForcelist as the reference.
Here I've specified the ID for the extension that gets generated when it was loaded in unpacked format. Also, I used the local HTTP server as the place to download. A pseudo value of the property that I used:
eelojgpfkmaaabbbccneneemcahoehjo;http://<some.ip.address>/crx
See attached snapshot for reference:
I've created an IIS server and enabled Directory browsing and then chose the root path of the server to point to the parent folder of 'crx'. I am able to access an xml file present inside crx using this above URL.
However my extension is still not installed. But I also have the extension in the Chrome Webstore and if I use the Webstore URL, the extension is deployed successfully.
As per comments from Xan below and further trials that I performed, I'll add the snapshots for each of the following:
1.
2. Tried FQDN instead of IP address but still couldn't install
3. Changed the GPO to point to the folder that contains the crx file instead of the update URL. Still not installed
4. I had already packed the extension using the link you mentioned. I dragged-n-dropped this packed crx file and found out the new ID. I then used this ID in my updates.xml file as well as in my Chrome GPO policies. However, extension is still not installed on the domain endpoint.
Can someone please help me point out exactly what is missing?
Is there some issue in the way I configured my IIS server? or
Could it be because I used an IP address instead of an FQDN? or
Is it because of some other possible configuration error?
You don't specify this well in your question, but I spot a few problems/omissions:
CRXs and IDs
Here I've specified the ID for the extension that gets generated when it was loaded in unpacked format.
This will not work; that ID is just a temporary one based on the hash of the path to the extension.
Chrome needs to generate a keypair and sign the CRX for it to be useable in enterprise deployment.
You need to package it as CRX through chrome://extensions's Developer Mode.
It will generate a private key .pem that you need to save for any future updates (otherwise the ID will change again and you won't be able to use it as an update).
Then, install the CRX on the same machine by dragging it onto chrome://extensions to get its final, signed ID.
As an alternative to this step, you can use OpenSSL to generate the key from the .pem obtained from the previous steps.
What are you actually hosting?
The URL that you point to in the GPO policy is the Update URL, not the actual CRX file!
See this documentation on Update manifests. Here's an example:
<?xml version='1.0' encoding='UTF-8'?>
<gupdate xmlns='http://www.google.com/update2/response' protocol='2.0'>
<app appid='eelojgpfkmaaabbbccneneemcahoehjo'>
<updatecheck codebase='http://<some.ip.address>/actual_extension.crx' version='1.0' />
</app>
</gupdate>
Modify the updatecheck.version as needed when updating. Don't touch any of the gupdate properties.
How are you serving files?
There may be a minor issue with content-types your server is sending.
I could not find bulletproof information on what should be the content type for the files, but a good guess is:
application/xml for the update manifest
application/octet-stream for the CRX file
Still not working?
Perhaps you're on to something with IP vs FDQN. It should be possible for you to create a local DNS entry for the update server - try and see if it helps.
Here's an Alternative Extension Distribution Options documentation for the possible ways on how to distribute Chrome extensions.
All Chrome extensions must be distributed either directly from the Chrome Web Store, using inline installation, or using the mechanisms described below. Failure to comply with one of these distribution methods constitutes a violation of the Chrome extension policy and may result in the extension and/or the software distributing it to be flagged as unwanted software.
You may also check this support page if you want to force install Chrome extensions on corporate-managed Windows devices via machine and OS-user policies.
I have a windows application which installs a Chrome extension via the windows registry. I wish for this application to generate some one-time information for Chrome to read based on information typed in by the user during the installation process.
Assuming I am not using NPAPI in the Chrome extension, is there anywhere the installer can place information such that the extension will see it?
Edit: I also wish to launching chrome at the end of the installation.
Another way you can pass information to an installed extension from outside of Chrome is to have a page with your extension that you then open Chrome too and pass the info in the hash...such as....
chrome.exe "chrome-extension://emcggffhhapbbkcodabdliakappfibcf/showHash.html#info"
Problem with this method is your installing the extension using the simple registry method (Im guessing) and not using the Policy method. With the Policy method you can force an install and it will happen even if Chrome is allready open (where as according to the docs the simple method happens the next time Chrome is opened). Downside to this is you will have to make an uninstaller yourself as you cant uninstall an extension from Chrome that is installed with this method. Im also not sure how quick/often it will be before the extension is installed (couldnt find it in the docs and too lazy to try it ;)) and youd need to make your installer wait a bit for it to be installed....
http://www.chromium.org/developers/how-tos/adding-new-policies
http://dev.chromium.org/administrators/policy-list-3#ExtensionInstallForcelist
http://dev.chromium.org/administrators/policy-templates (says where in the registry to add them)
Another possible method could be to pack the extension at install time and add a file with the info that the extension could read. Problem with this method is that the extensions ID would change (might not be a problem for you?) or youll have to include the PEM in your installer which you probably dont want to do....
chrome.exe --pack-extension="C:\simple-example" --no-message-box
Many people wish there were an event firing on extension installing.
There's a workaround, not elegant way to send info to the browser from outside: launch chrome asking to open an url.
I use it with a local html file. My application execute a command line like:
"pathToChrome\Chrome.exe" "file://pathToHtmlFile/myFile.html?param1=value1¶m2=value2"
The info I pass are the page's parameters.
The catch is that this page is read by the extensions in one of many ways:
You can write a content script this page will fire
You can put some javascript on this page to write down the parameters as cookies, for the extension to read in the future (without calling the extension at this time)
It hasn't to be a local page. If your page is on a server, it can save the parameters in the server, ir it worthy.
It hasn't to be even your page. You can call any page on Internet, but beeing sure it will fire your content script extension, and it will read your "customized" parameters.
Instead of communicating through the windows registry, you can create a WebSQL from the installer and from the extension read the data from there.
You will need to a bit of research about how to this, but this is possible. the steps should be:
The installer will create the database and register to chrome (maybe with the Databases.db)
The extension will use openDatabase to create a connection to the database
The extension will do a transaction and read the needed file.
Another option is to add file to the crx for example "installer_info.json" and do an AJAX request from the extension to the "installer_info.json" file.
There is no formal way for doing this things, little research and you will have a way.