Greasy Fork

@devs: Tampermonkey's upcoming support of @connect may break scripts with GM_xmlhttpRequest

To all userscript developers.

Tampermonkey beta now supports @connect and when it's absent an obscure confirmation page is displayed by Tampermonkey where it's not that easy to decide what to click for a user who doesn't know about these security specifics, especially in the limited amount of time the page is displayed. This may lead to an automatic blocking of XHR for the userscript, and it's not something that can be undone easily by a non-savvy user.

To fix this you should update your userscripts that use GM_xmlhttpRequest:

• when the userscript fetches only from a few known domains:

  // @connect domain1.com
  // @connect domain2.com
  // @connect sub.domain3.com
  // @connect *.domain4.com
  

or // @connect self to whitelist the current URL or // @connect none to prevent loading resources from any source.

• otherwise allow everything:

  // @connect *

Quote from the documentation:

If it's not possible to declare all domains a userscript might connect to then it's a good practice to do the following: declare all known or at least all common domains that might be connected by the script. This way the confirmation dialog can be avoided for most of the users.

Additionally add @connect * to the script. By doing so Tampermonkey will still ask the user whether the next connection to a not mentioned domain is allowed, but also offer a "Always allow all domains" button. If the user clicks at this button then all future requests will be permitted automatically.

Users can also whitelist all requests by adding '*' to the user domain whitelist.

is this related to greasemonkey/greasemonkey#1052?

Good information, thanks

@ts, seems so. Apparently Content Security Policy's connect-src wasn't developed back in 2009 otherwise I don't know why it wasn't mentioned.

Hi, thanks for the feedback.

GM_xhr is the most powerful API of Tampermonkey, but also the one with the highest potential for abuses. If for example the jQery CDN is hacked then normal pages don't have issues with other data besides their own (i.e. user credentials). But a Userscript with such a jQuery @require and GM_xhr permission allows the malicious code to interact with for example your banking page when you're logged in.

That's why I feel it's a good idea if Userscripts clearly state the domains they talk to. I'm still experimenting with this feature and I'm open to discussions, also regarding the name. @connect-src, @connect, @domain, @xhr-include, @limit-requests-to, @limitXHR, ...

it's pretty hard to decide whether to press the "Allow" button in the limited amount of time the page is displayed The dialog timeout depends on the GM_xhr.timeout option, but with a minimum of 10 seconds. You can also stop the timeout by pressing the "Skip timeout" button. However, I'll increase the timeout to a minimum of 20 seconds and position the button more prominently. I'll also add a little help text to the page once I figured out what to write.

if you press "Allow" once to allow one domain, Tampermonkey will never ask again for other domains This will be fixed at the next version.

otherwise allow everything: @connect-src * won't work anymore at future versions cause it reduces the concept to absurdity.

And finally there is another thing that should be mentioned: if a userscript contains a @connect-src statement, then all non-matching request will be denied. The confirmation dialog is really only shown if the TM setting is set to "ask" and no directive is given.

@connect-src * won't work anymore at future versions cause it reduces the concept to absurdity.

What do you think this change will do to global site enhancers like Mouseover Popup Image Viewer userscript? I think it might be much better to show the warning during the installation of such userscript that it may access all sites like Chrome does when you install an extension.

i prefer connect-src * works in following versions, and this should be default value if no connect-src given.
a warning msg is enough.

i vote @xhr-domain .
@xhr-include should check the whole url and accept both string & regexp in my mind.

What do you think this change will do to global site enhancers like Mouseover Popup Image Viewer userscript?

Good point. So @connect-src * will enable the confirmation dialog for all non-listed domains. This means the dialog can be avoided quite often by just stating all well-known domains.

i prefer connect-src * works in following versions, and this should be default value if no connect-src given. In my opinion a confirmation-less connect-src * default will lead to no change at all. But you can achieve exactly this behavior by setting the "@connect-src mode" to "Casual".

I also added buttons to generally grant/deny all further requests. I think this is the better way cause if a script only connects to well-know domains no warning is necessary at all.

And last but not least: everybody can configure this feature at TM's settings. The possibilities last from "I don't care"("off") to paranoid("always ask").

Sounds reasonable to me

Maybe I'm a bit late; are we using @connect, @connect-src or is the meta name is still WIP?

Thanks.

I think @connect sounds good. It's short and expressive. So unless half of the developers here raise an objection this will be the name. :)

I think @connect sounds good. It's short and expressive. So unless half of the developers here raise an objection this will be the name. :)

Thank you :)

It would be cool to include this in the install dialog.

Either 1) the user accepts that the script should have access or 2) it isn't installed.

Having a script that cant access its resources is rarely useful.