You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is useful to calculate the Chrome extension ID corresponding to a given a private key. For instance, in order to run WebDriver functional tests for any Google Extension using Selenium–ChromeDriver, the extension ID is necessary to get the URLs of extension pages (background and popup pages).
The module API would be similar to crx.generateExtensionID() or ChromeExtension.getExtensionIdFor(privateKeyBuffer), and the CLI would be similar to crx genid -p private-key. The interfaces might also support public keys as inputs, since any private keys would simply be converted to public keys anyway, but this flexibility should be weighed against API simplicity.
The text was updated successfully, but these errors were encountered:
Hello @js-choi, I was not aware of this feature but yes, it would be a good addition.
I would indeed favour a #getExtensionIdFor(publicKeyBuffer) to return a promise, because the public key is the real dependency. The #generatePublicKey() method would provide the required data if it is not already available within the workflow:
It is useful to calculate the Chrome extension ID corresponding to a given a private key. For instance, in order to run WebDriver functional tests for any Google Extension using Selenium–ChromeDriver, the extension ID is necessary to get the URLs of extension pages (background and popup pages).
As Erik Kay says on Stack Overflow, any extension’s ID is the first 128 bits of the SHA256 of its RSA public key encoded in base 16 from
a
top
. CLI examples from Rob Wu and a Ruby script by Mark Wubben might also be useful to look at.The module API would be similar to
crx.generateExtensionID()
orChromeExtension.getExtensionIdFor(privateKeyBuffer)
, and the CLI would be similar tocrx genid -p private-key
. The interfaces might also support public keys as inputs, since any private keys would simply be converted to public keys anyway, but this flexibility should be weighed against API simplicity.The text was updated successfully, but these errors were encountered: