-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
webpage or its components should not attempt to message an extension directly #13
Comments
why not have both options? the direct way of communication may be more performance for some use cases. |
The performance overhead of forwarding a message is negligible, right? If an extension service-worker is required to listen to messages from anywhere, it wouldn't know which sources to trust. The service-worker should only be required to listen to messages from its own ContentScript (and the extension's other app content). The design of an extension shouldn't be otherwise constrained. The protocol and messages between a page and an extension should only concern the messages (and maybe other content but hopefully not) between the page and the ContentScript. |
I'm not sure that the performance is negligible and you get the benefit of inline response. The service worker only needs to listen to trusted web pages that were authorized by the users. I still don't get your point of restricting messages only from content script. I think that content script exists primarily to allow the service worker to directly interact with the DOM of the web page. |
Well, I've stated most of my case already. Among other things, my implementation for KERI Auth doesn't use messaging, but uses ports, so that means I'd need to change that or not implement AutoSignin until needed. |
that's because chrome implements the externally_connectable feature that allow the service worker to receive messages in a specific listener |
Does that imply for the extension to use the Auto SignIn feature ( handleRequestAutoSignin on chrome or brave) that its manifest needs add the "externally_connectable" section and declare the sites it trusts? Hmm. |
The ideal case is that the user grant permission at runtime as with |
In the requestAutoSignin implementation in polaris-web (used by https://github.com/WebOfTrust/signify-browser-extension/blob/909803e6ad0a1038aa8d4ffea914767d98ea2894/example-web/my-app/src/App.js#L74),
polaris-web/index.js
Line 81 in 697eb6a
it attempts to contact the extension directly via chrome.runtime.sendMessage(). It should always communicate via the extension's ContentScript. The webpage and a compliant ContentScript should have a "contract" of message types. The ContentScript and its Extension (service-worker) must have a completely independent contract of message types and ways of communicating. The web page and polaris-web should know nothing about the latter. For example, in the case of KERI Auth extension, it will use chrome ports, not messages, and will ignore all messages.
The text was updated successfully, but these errors were encountered: