Extensions Click-to-Script: Permissions API behavior |
|||||
Issue descriptionThe permissions API can be used to query permissions, and request permissions from the user. Currently, querying permissions works correctly with click-to-script (though we should add a test for this) - an extension with withheld permissions correctly sees those permissions as not present when using permissions.contains() or permissions.getAll(). We also don't withhold permissions that are optional permissions that have been granted through permissions.request() (since these are fairly runtime-y). However, we don't currently allow extensions to request withheld permissions through permissions.request(), since we currently restrict that to permissions specified as optional. We may want allow permissions.request() to be used for withheld required permissions, to give extensions a possibly easier migration path. (though the alternative of having the developer simply add it as an optional permission is also reasonable.)
,
Sep 28
,
Oct 3
Hi, Tampermonkey dev here. Yesterday I played with runtime host permissions and found some problems. Tampermonkey for example needs to check for userscript updates, but I don't know the sources of all the userscripts that might by installed, so I can't add them to my manifest as optional permission. There a two possible solutions from my point of view: 1) be able to request the <all_urls> permission again (which is what this issue is about) or 2) request a host permission for all hosts that Tampermonkey needs to connect to. If you think about implementing 2) as well, then it would be nice if I could somehow check if all extension runtime host permissions already include access to a given origin. (i.e. use chrome.permissions.contains to query for access to https://example.com) Thanks.
,
Oct 3
Hey there! Re 1), extensions can still request <all_urls> (and, as of today, it will be autogranted on installation). The difference is that the user will have the option to "un-grant" this permission. But if the user chooses to (continue to) allow Tampermonkey on all sites, it will have permission to do so, and can continue operating normally. For 2), this should work today - chrome.permissions.contains() and chrome.permissions.getAll() will correctly report the current permissions the extension has available to it, taking into account whether or not the user withheld any. So, if the user installs Tampermonkey, withholds the <all_urls> permission, and then grants "https://example.com/*", permissions.contains({origins:["https://example.com/*"]}) will return true, and getAll() will include example.com, but not <all_urls>. Does that work for your use case? (The remaining work in this bug is about potentially allowing permissions.request() to request withheld hosts, since currently it requires the request to be in optional_permissions.)
,
Oct 3
Thanks for your quick response. > The difference is that the user will have the option to "un-grant" this permission. But if the user chooses to (continue to) allow Tampermonkey on all sites, it will have permission to do so, and can continue operating normally. I know, but like the idea of limiting extensions to what is really necessary. That's why I'll try to make Tampermonkey work with limited permissions as good as possible. The problem (which is desired behavior) is that once the <all_urls> permission is denied (This can read and change site data -> When you click the extension), all background page CORS requests to unpermitted hosts fail. Unfortunately userscripts are hosted at many different pages (i.e. https://raw.githubusercontent.com/) which are unlikely to be visited by users (and even if they visit the site, the user would have to click the Tampermonkey badge icon to allow userscript updates, which is not really obvious). I simply don't know how to request permission from the user to access raw.githubusercontent.com via background page without opening a tab and explain them to visit the page(*). My favorable solution would be chrome.permissions.request({ origins: [ 'https://raw.githubusercontent.com/*' ] }), but this returns(**) "Optional permissions must be listed in extension manifest." > So, if the user installs Tampermonkey, withholds the <all_urls> permission, and then grants "https://example.com/*", permissions.contains({origins:["https://example.com/*"]}) will return true, and getAll() will include example.com, but not <all_urls>. This doesn't work here(**). Tampermonkey is allowed to run at https://greasyfork.org (by clicking at the extension icon), but chrome.permissions.getAll(function(a) { console.log(JSON.stringify(a)) }); logs {"origins":["chrome://favicon/*"],"permissions":["clipboardWrite","contextMenus","cookies","idle","management","notifications","storage","tabs","unlimitedStorage","webNavigation","webRequest","webRequestBlocking"]} and chrome.permissions.contains({origins:["https://greasyfork.org.com/*"]}, function(r) { console.log(r) }); returns false. I'm using Ubuntu and updated all Chromes today, but maybe I have to wait for a new release? (*) = https://raw.githubusercontent.com/ameboide/webcomic_reader/master/webcomic_reader.user.js is still caught by Chrome saying "Apps, extensions and user scripts cannot be added from this site". So I would have to guess a page based on the source URL which doesn't result in an error page or is redirected to another host. (**) = using Version 71.0.3559.6 (Official Build) dev (64-bit) and Version 70.0.3538.45 (Official Build) beta (64-bit)
,
Oct 3
> The problem ... is that once the <all_urls> permission is denied..., all background page CORS requests to unpermitted hosts fail.
Yep, this is a known rough spot. We're contemplating what, if anything, we can provide as a workaround here (since obviously we do still need to respect user permission settings).
> My favorable solution would be chrome.permissions.request({ origins: [ 'https://raw.githubusercontent.com/*' ] }), but this returns(**) "Optional permissions must be listed in extension manifest."
That's what the remainder of this bug is about - being able to request withheld permissions. I think it probably makes sense to do this.
>> So, if the user installs Tampermonkey, withholds the <all_urls> permission, and then grants "https://example.com/*", permissions.contains({origins:["https://example.com/*"]}) will return true, and getAll() will include example.com, but not <all_urls>.
> This doesn't work here(**). Tampermonkey is allowed to run at https://greasyfork.org (by clicking at the extension icon)
Sorry, I should have clarified. You will be able to query if you have "sticky" access to any specific origin. That is, if the user granted access through the context menu -> Always run on example.com, or entered the URL in the chrome://extensions page. If the user just clicked on the extension on a given site, the permissions API will not include the origin, because it's only granted permission on a single tab, and only while the user is on that origin. However, when the user clicks on an extension that wants to run on a site, it should run the pending actions for the extension (e.g., inject the content script), which would allow you to detect the access.
I also wonder if we could either extend permissions.onAdded or add a new event to indicate when activeTab is granted. That might be something we think about.
,
Oct 4
> That's what the remainder of this bug is about - being able to request withheld permissions. This is great, I just wanted to make sure that "withheld permissions" here includes single host permissions even if they are not explicitly named, but implicitly are a part of the <all_urls> permission. > Sorry, I should have clarified. You will be able to query if you have "sticky" access to any specific origin. Ah OK, user error. It's working fine now. :)
,
Oct 8
We should also probably not let the extension silently re-add an optional host permission which was revoked by the user. (i.e. instead of checking granted permission set, check runtime granted set when an extension tries adding an optional host permission).
,
Oct 25
Hello, in terms of the ability to re-request permissions, but only optional permissions, I've seen some strange behavior with requesting `all_urls` back. After "just this site" or "on click" is selected, it looks like programmatically re-requesting `<all_urls>` works strangely with the new permissions management UI. When the request is granted (after the dialogue), the right-click menu shows "all sites" when going to do extension permissions management, but content scripts do not return to their normal injected behavior, the way they do when "All Sites" is manually re-selected in the UI. However, there does not seem to be clean API to detect this state of changed allowed content-script injection (or any way to ask for it to be restored in parallel?). My colleague Will posted an example and question to the chromium extensions google group: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-extensions/nbyynbf_a_w, but it seemed relevant to the discussion here.
,
Oct 25
@9 Thanks for bringing this up! The permissions API currently only looks like explicit host permissions (i.e., those specified in the "permissions" manifest key. As part of expanding this to work better with runtime hosts, I'll see how we can tweak it to deal with content script permissions, as well.
,
Nov 13
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b236ad489129aebf6b0cffc76943be54f54edb88 commit b236ad489129aebf6b0cffc76943be54f54edb88 Author: Devlin Cronin <rdevlin.cronin@chromium.org> Date: Tue Nov 13 03:32:07 2018 [Extensions Click-to-Script] Adjust permissions API for withheld permissions Adjust the chrome.permissions API for use with withheld permissions as a result of the RuntimeHostPermissions feature. This patch allows the permissions API to be used to request withheld or optional host permissions, rather than just optional host permissions. This is important for extensions that want to be able to request permissions at runtime using the chrome.permissions API as a workaround to having required permisssions withheld. Additionally, move requesting optional permissions to looking at the runtime granted permission set, rather than the granted permission set. This greatly simplifies the logic, as now all permission requests are compared to the same permissions set, and we don't need to isolate host permission requests versus API permission requests. This also ensures we avoid granting a permission that was explicitly revoked by the user (as could happen if we just checked granted permissions). As of Chrome 70, all permissions granted through the permissions API are added to the runtime granted set. However, this does mean that optional permissions that were granted prior to M70, and then later removed via permissions.remove(), will re-prompt the user. In practice, this is very rare. This also means that optional permissions will not be granted automatically for permissions that were used by previous versions of the extension (similarly, very rare in practice). This does *not* address the issue of scriptable hosts in requested permissions; that is still an issue. Bug: 889654 Change-Id: I8c20f03ec7b402cd61ae1db04b782447dc39414e Reviewed-on: https://chromium-review.googlesource.com/c/1301851 Commit-Queue: Devlin <rdevlin.cronin@chromium.org> Reviewed-by: Karan Bhatia <karandeepb@chromium.org> Cr-Commit-Position: refs/heads/master@{#607474} [modify] https://crrev.com/b236ad489129aebf6b0cffc76943be54f54edb88/chrome/browser/extensions/api/permissions/permissions_api.cc [modify] https://crrev.com/b236ad489129aebf6b0cffc76943be54f54edb88/chrome/browser/extensions/api/permissions/permissions_api.h [modify] https://crrev.com/b236ad489129aebf6b0cffc76943be54f54edb88/chrome/browser/extensions/api/permissions/permissions_api_unittest.cc [modify] https://crrev.com/b236ad489129aebf6b0cffc76943be54f54edb88/chrome/browser/extensions/api/permissions/permissions_apitest.cc [modify] https://crrev.com/b236ad489129aebf6b0cffc76943be54f54edb88/chrome/test/data/extensions/api_test/permissions/host_subsets/background.js [modify] https://crrev.com/b236ad489129aebf6b0cffc76943be54f54edb88/chrome/test/data/extensions/api_test/permissions/optional/background.js
,
Nov 28
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/075e36f16360d0ad0af7d860830c37402fc46cec commit 075e36f16360d0ad0af7d860830c37402fc46cec Author: Devlin Cronin <rdevlin.cronin@chromium.org> Date: Wed Nov 28 20:20:40 2018 [Extensions Click-to-Script] Refactor parsing in permissions API Refactor the permissions parsing in the chrome.permissions API in order to separate out requested permissions into different fields, including required permissions, optional permissions, and permissions that were not specified in the manifest. Add more robust testing for the permissions parsing code. This CL is prework for subsequently adding support for requesting withheld content script permissions through the permissions API. There should be no behavior change as a result of this CL. Bug: 889654 Change-Id: I22c1e057ccb259b4fcff4051923fc9c1128c8213 Reviewed-on: https://chromium-review.googlesource.com/c/1347310 Commit-Queue: Devlin <rdevlin.cronin@chromium.org> Reviewed-by: Karan Bhatia <karandeepb@chromium.org> Cr-Commit-Position: refs/heads/master@{#611846} [modify] https://crrev.com/075e36f16360d0ad0af7d860830c37402fc46cec/chrome/browser/extensions/api/permissions/permissions_api.cc [modify] https://crrev.com/075e36f16360d0ad0af7d860830c37402fc46cec/chrome/browser/extensions/api/permissions/permissions_api_helpers.cc [modify] https://crrev.com/075e36f16360d0ad0af7d860830c37402fc46cec/chrome/browser/extensions/api/permissions/permissions_api_helpers.h [modify] https://crrev.com/075e36f16360d0ad0af7d860830c37402fc46cec/chrome/browser/extensions/api/permissions/permissions_api_helpers_unittest.cc [modify] https://crrev.com/075e36f16360d0ad0af7d860830c37402fc46cec/chrome/test/data/extensions/api_test/permissions/optional/background.js [modify] https://crrev.com/075e36f16360d0ad0af7d860830c37402fc46cec/chrome/test/data/extensions/api_test/permissions/optional/manifest.json
,
Nov 29
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/71f24f632bbef2989fbe6df44877da0395f06e69 commit 71f24f632bbef2989fbe6df44877da0395f06e69 Author: Devlin Cronin <rdevlin.cronin@chromium.org> Date: Thu Nov 29 00:06:21 2018 [Extensions Click-to-Script] Support content scripts in the permissions API Add support for extensions requesting content script permissions in the permissions API. This allows extensions to request withheld content script permissions through chrome.permissions.request(). Add tests to cover the same. Bug: 889654 Change-Id: I0b77215ec154e42d1152df3277307d0383cda204 Reviewed-on: https://chromium-review.googlesource.com/c/1347061 Reviewed-by: Karan Bhatia <karandeepb@chromium.org> Commit-Queue: Devlin <rdevlin.cronin@chromium.org> Cr-Commit-Position: refs/heads/master@{#611945} [modify] https://crrev.com/71f24f632bbef2989fbe6df44877da0395f06e69/chrome/browser/extensions/api/permissions/permissions_api.cc [modify] https://crrev.com/71f24f632bbef2989fbe6df44877da0395f06e69/chrome/browser/extensions/api/permissions/permissions_api_helpers.cc [modify] https://crrev.com/71f24f632bbef2989fbe6df44877da0395f06e69/chrome/browser/extensions/api/permissions/permissions_api_helpers.h [modify] https://crrev.com/71f24f632bbef2989fbe6df44877da0395f06e69/chrome/browser/extensions/api/permissions/permissions_api_helpers_unittest.cc [modify] https://crrev.com/71f24f632bbef2989fbe6df44877da0395f06e69/chrome/browser/extensions/api/permissions/permissions_api_unittest.cc
,
Nov 29
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7edce81aa840df30df053092aec668eea7f80426 commit 7edce81aa840df30df053092aec668eea7f80426 Author: Devlin Cronin <rdevlin.cronin@chromium.org> Date: Thu Nov 29 21:41:50 2018 [Extensions Click-to-Script] Adjust permissions packing for getAll() Adjust the permissions packing code in the chrome.permissions extension API to include scriptable hosts, as well as explicit hosts. This will result in permissions.getAll() returning origins that are specified in the content_scripts section of the manifest, in addition to the hosts specified in the permissions key. Update tests for the same. Bug: 889654 Change-Id: I5dba0bc225bdcb30b969f48f9405f92b1ec8bd58 Reviewed-on: https://chromium-review.googlesource.com/c/1347441 Reviewed-by: Karan Bhatia <karandeepb@chromium.org> Commit-Queue: Devlin <rdevlin.cronin@chromium.org> Cr-Commit-Position: refs/heads/master@{#612376} [modify] https://crrev.com/7edce81aa840df30df053092aec668eea7f80426/chrome/browser/extensions/api/permissions/permissions_api_helpers.cc [modify] https://crrev.com/7edce81aa840df30df053092aec668eea7f80426/chrome/browser/extensions/api/permissions/permissions_api_helpers_unittest.cc [modify] https://crrev.com/7edce81aa840df30df053092aec668eea7f80426/chrome/browser/extensions/api/permissions/permissions_api_unittest.cc [modify] https://crrev.com/7edce81aa840df30df053092aec668eea7f80426/chrome/browser/extensions/permissions_updater_unittest.cc [modify] https://crrev.com/7edce81aa840df30df053092aec668eea7f80426/chrome/test/data/extensions/api_test/permissions/optional/background.js [add] https://crrev.com/7edce81aa840df30df053092aec668eea7f80426/chrome/test/data/extensions/api_test/permissions/optional/content_script.js [modify] https://crrev.com/7edce81aa840df30df053092aec668eea7f80426/chrome/test/data/extensions/api_test/permissions/optional/manifest.json
,
Nov 29
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/26a7d45a63d63666ce57be60a84432193fbf81d6 commit 26a7d45a63d63666ce57be60a84432193fbf81d6 Author: Devlin Cronin <rdevlin.cronin@chromium.org> Date: Thu Nov 29 22:21:05 2018 [Extensions Click-to-Script] Update permissions docs Update the permissions API documentation to note that: - "origins" contains origins associated with content scripts - The API can be used to request permission that were withheld by the user. Bug: 889654 Change-Id: I63cbc3f4e80e6cc26532e9714dd8de7a8086b97c Reviewed-on: https://chromium-review.googlesource.com/c/1347039 Commit-Queue: Devlin <rdevlin.cronin@chromium.org> Reviewed-by: Karan Bhatia <karandeepb@chromium.org> Cr-Commit-Position: refs/heads/master@{#612404} [modify] https://crrev.com/26a7d45a63d63666ce57be60a84432193fbf81d6/chrome/common/extensions/api/permissions.json
,
Nov 29
As of now, the permissions API should be usable to request host permissions that were withheld by the user for both the patterns specified in "permissions" as well as "content_scripts". Please allow a couple of days for this to hit Canary, but you should be able to test it out there soon. Let me know if you run into any issues here, and thank you for bringing these up!
,
Dec 5
The NextAction date has arrived: 2018-12-05
,
Dec 5
If no one's seen any additional issues here, I'll go ahead and close this one out.
,
Dec 7
The NextAction date has arrived: 2018-12-07
,
Dec 7
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by bugdroid1@chromium.org
, Sep 27