6

I use match to restrict my script to work only one domain but chrome runs it in every domain. I tried @include and @match and it says "Access your data on all websites" when I try to install it and it runs it in all websites.

How can I restrict userscript to one domain in chrome?

Metadata is same as this page: http://www.chromium.org/developers/design-documents/user-scripts

I mean it's:

// @match http://*.google.com/*
// @match http://www.google.com/*
Brock Adams
  • 90,639
  • 22
  • 233
  • 295
Someone
  • 728
  • 2
  • 12
  • 23
  • Are you trying to install a zip / crx file or a `.user.js` file? – Rob W May 06 '13 at 16:40
  • i said userscript so it's .user.js – Someone May 06 '13 at 16:41
  • Chrome converts user scripts to native Chrome extensions with a match pattern equivalent to ``, then restricts the pages by via `"include_globs"`. Don't worry about the warning, it behaves as you expect. If you want to get a less scary warning, you need to create a Chrome extension from your user script, and edit the "content_scripts"` part of the `manifest.json` file. See [this answer](http://stackoverflow.com/questions/11772308/keep-same-id-when-converting-from-userscript-in-chrome/11773654#11773654) for the steps to generate a Chrome extension from a user script. – Rob W May 06 '13 at 16:45
  • it doesn't behave as expected. it runs script on all pages instead of one domain as i said in question. – Someone May 06 '13 at 16:47
  • Show the metadata header of your script in the question. – Rob W May 06 '13 at 16:48
  • there's no problem with metadata. http://www.chromium.org/developers/design-documents/user-scripts – Someone May 06 '13 at 16:52
  • Well you say that but it's not like that. There's no problem with metadata and it still runs on all domains. I edited question. – Someone May 06 '13 at 16:56
  • 1
    The example you've linked contains `http://*/*`. Obviously that's going to run on all pages. I've also checked the autogenerated `manifest.json`, and it contains the expected values. Read http://stackoverflow.com/a/11773654/938089 to learn how to get and find the autogenerated `manifest.json` file. EDIT: After removing `// @matches http://*/*`, the code only runs on Google - as expected. – Rob W May 06 '13 at 17:01
  • Well code doesn't run only on google as expected. It runs on all domains. And this is autogenerated manifest: http://pastebin.com/u9C9PXTs and of course it doesnt have http://*/* in script. When I said there's no problem with metadata I mean there's no problem with metadata. – Someone May 06 '13 at 17:11
  • I already showed metadata in question – Someone May 06 '13 at 17:15
  • And that causes http://pastebin.com/SH21WFAB to be generated. If you want help, put the metadata in your question. Until you do, I won't respond to your comments any more, because it's not productive. – Rob W May 06 '13 at 17:16
  • I don't know what are trying to say. I said I already showed metadata in question. And yes metadata in the question generates that: http://pastebin.com/u9C9PXTs I don't why it generates different metadata in your computer but I showed you what it generates in my computer. What can I do to convince you? Why should I lie to you? – Someone May 06 '13 at 17:23
  • Did you also add the `// ==UserScript==` and `// ==/UserScript==` parts of the meta data block? – Rob W May 06 '13 at 17:25
  • Yes I tried with them and without them. I also tried with @include – Someone May 06 '13 at 17:26
  • Ok problem solved. My file was encoded with UTF8 and when I save it as ANSI it correctly generated metadata and it's now run only one domain. I don't know it's chrome's bug or not but it generates metadata as "all domains" if file is UTF8. – Someone May 06 '13 at 17:38
  • Probably this bug: https://code.google.com/p/chromium/issues/detail?id=102667 ("User script header does not parse if UTF8 BOM is present") – Rob W May 06 '13 at 17:40
  • Anyway there's no problem with ANSI now. Thanks for your efforts. – Someone May 06 '13 at 17:43
  • 1
    Please post an answer with the solution (and remove some comments which are probably not useful to future readers). Others may benefit from your findings. – Rob W May 06 '13 at 17:46

1 Answers1

7

Note: this answer developed between the OP and Rob W.   Placing it here in the hopes that this question might be useful to others without having to sift through the comment chain, above.


There are two issues. First, a userscript header does not parse if a UTF8 BOM is present (Chromium bug 102667).

Second, when using @include versus @match in a userscript, Chrome misleadingly reports that the script can "Access your data on all websites", but this is not really true. The script will run on only those sites specified by the include statement(s).

Consider (or make) these three scripts:

UTF test, not UTF.user.js (save with ANSI encoding):

// ==UserScript==
// @name    Not UTF source file
// @match   http://www.yahoo.com/*
// ==/UserScript==
if (location.hostname != 'www.yahoo.com')
  alert ("This script should not run on "+location.hostname+"!");


UTF test, is UTF.user.js (save with UTF-8 encoding, including the BOM):

// ==UserScript==
// @name    Is UTF source file
// @match   http://www.yahoo.com/*
// ==/UserScript==
if (location.hostname != 'www.yahoo.com')
  alert ("This script should not run on "+location.hostname+"!");


Include, not match.user.js (save with ANSI encoding):

// ==UserScript==
// @name    Use include, not match
// @include http://www.yahoo.com/*
// ==/UserScript==
if (location.hostname != 'www.yahoo.com')
  alert ("This script should not run on "+location.hostname+"!");


Note that all 3 scripts are the same code. Only the @name and/or the file-format and/or @include versus @match are different.


The ANSI script, with match (UTF test, not UTF.user.js) reports these permissions:

ANSI plus match
This script operates and reports correctly, and as expected.


The UTF-8 script, with match (UTF test, is UTF.user.js) reports these permissions:

UTF plus match
The permissions are reported incorrectly, contradicting the @match statement(s). Also note that the file-name is shown, URL-encoded, instead of the @name directive. These are both clues that something is amiss.

Worse, this script will operate on all sites. That is, you will see the alert() on all non-Yahoo pages. This is clearly a bug.


The ANSI script, with include (Include, not match.user.js) reports these permissions:

ANSI plus include
While this is a misleading report, the script will actually operate correctly. That is, it will only fire for yahoo pages.

This is due in part to how Chrome auto-converts userscripts into extensions. @match statements are translated directly into the manifest.json's matches property, while @include statements are made into include_globs values. See Match patterns and globs. The permissions report keys off the matches array.

Brock Adams
  • 90,639
  • 22
  • 233
  • 295