Can we get sample for manifest v3 for modifying allowed hosts dynamically

[Yureshwar Ravuri]

Hi All,

I want to give the flexibility to the user to allow the extension to load on the web page that he was browsing which is not enabled in manifest. Is it possible in manifest v3 where it was mentioned for dynamic allowance. If so could you please guide me on how to implement even if it is in Beta version.

Thanks,

Yureswar Ravuri

[Simeon Vincent]

It's not possible to request access to a host that is not declared in the manifest. That said, you can use the activeTab permission to run on arbitrary hosts when invoked by the user. 

Simeon - @dotproto

Chrome Extensions DevRel

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/4e3faa44-633f-4be2-8b96-084297998d96n%40chromium.org.

[yureshwar ravuri]

Hi Simeon,

Thanks for your response. I'll explain further the problem I am facing.

I am the lead developer of an Open Source - Digital Adoption Solution (DAS) where we are developing a browser plugin that will guide users through feature-rich web applications.

https://github.com/kcramakrishna/Digital_Assistant_Client

For this to function well, we inject js via plugin 'content_scripts':

https://github.com/kcramakrishna/Digital_Assistant_Client/blob/master/chrome-plugin/manifest.json

We initially enabled all URLS '*' in the 'content_scripts -> matches -> allowed_hosts' = '*.*' and submitted to chrome store.

Chrome store rejected the plugin for privacy reasons. So we now want to restrict all URLs and allow the user to manually enable URLs of his choice (user can type in or paste URLs of his choice). We hope that this will solve the chrome store guidelines. We were exploring the v3 feature 'dynamic content scripts' to achieve this objective but your previous answer suggests that 'dynamic content scripts' is not the right approach.

How do I solve the problem of allowing an any/user-choice URL without hard-coding this in the manifest.json? We want to publish the plugin in the chrome store for the benefit of all chrome users. 

Can you please suggest any alternatives?

Please advise,

Thanks & Regards,
Yureshwar Ravuri
Mob: +91 9030003889
Mail: yure...@gmail.com

[Simeon Vincent]

We initially enabled all URLS '*' in the 'content_scripts -> matches -> allowed_hosts' = '*.*'

I'm confused by the use of '*' and '*.*' here. The manifest you linked doesn't use those patterns and I didn't see it used in the history of the manifest.json file you linked. Additionally, the repo you linked is an MV2 extension, not an MV3 one.

Chrome store rejected the plugin for privacy reasons

Can you share the rejection email or the extension ID? Offhand I can't think of a situation where I've seen an extension rejected for using <all_urls> (but it's quite late here so maybe I'm missing something?).

How do I solve the problem of allowing an any/user-choice URL without hard-coding this in the manifest.json? We want to publish the plugin in the chrome store for the benefit of all chrome users. 

Typically in an MV2 extension you would do this by adding <all_urls> to your list of optional_permissions and using chrome.permissions.request to request access to a host at runtime. The disadvantage to this approach is that MV2 does not support dynamic content scripts (MV3 docs, in development). Instead, you would have to use programmatic injection (MV2 docs) to inject the script at runtime. This is an important distinction because programmatic injection with executeScript cannot run a script at document_start.

Alternatively, you could inject a loader content script on all pages that checks the user's settings in order to determine if the rest of the extension's functionality should run on this page. If not, the loader ends without accessing the user's data.

Simeon - @dotproto

Chrome Extensions DevRel

[yureshwar ravuri]

Hi Simeon,

We have initially used *.* under manifest like below

"content_scripts": [
{
  "matches": ["*://*/*"],
  "js": ["js/injectscriptmodifier.js"],
  "all_frames": false,
  "run_at":"document_start"
},
{
  "matches": ["*://*/*"],
  "js": ["js/injectsdk.js"],
  "run_at":"document_end"
}
 ],

Can you share the rejection email or the extension ID? Offhand I can't think of a situation where I've seen an extension rejected for using <all_urls> (but it's quite late here so maybe I'm missing something?).

This was very long time back.

For dynamic content script you mean via "chrome.scripting.registerContentScript" ? 

I want to know whether we can inject upfrontly into head before the page renders so that i want to capture the clickable objects on the page by modifying "EventTarget.prototype.addEventListener"

Do let me know in case of further information required.

Thanks & Regards,
Yureshwar Ravuri
Mob: +91 9030003889
Mail: yure...@gmail.com

[guest271314]

I dynamically change host permissions by re-writing manifest.json using File System Access API https://github.com/guest271314/captureSystemAudio/blob/master/native_messaging/file_stream/app/set_externally_connectable.js then reloading the extension.

[Roberto Oneto]

Hi everybody,
Very interesting topic in deed.
I didn't understand the reasons that lead you to this.
I seem to understand that your extension must be able to access any host and that your content script must necessarily be injected at "document_start".
So with MV3 you are at an impasse 'cause at the moment this feature can be considered "broken" or "still under maintenance".

But I don't understand your last post.
You claim to have solved the problem with File System Access API.
I have two questions about it:

1) Using this API to access the manifest.json file does not necessarily mean asking the user (with a user gesture) to select this file exactly

in the folder where the extension is installed from the CWS?

2) Once you rewrite the manifest.json and reload the extension, doesn't it automatically invalidate?

[guest271314]

1. I do not use CWS. The approach described is when using an unpacked extension locally.

2. See 1. The reason I use the approach described is for the ability to run Native Messaging at any URL.