Will Userscripts support the update of greasy fork's user script?

[JOJOforshaun]

https://greasyfork.org/en/help/rewriting
And,Can Userscripts be installed by clicking the Install button of the greasy fork like Tamperonkey?

[quoid]

@JOJOforshaun

Thanks for sharing this. I do not know the implications of this but if a script lacks @updateURL, @installURL, and @downloadurl - it will not be able to be updated currently, but perhaps this can be changed once I have a better understanding of this change from Greaseyfork.

Is there any more information on this? and why this is happening?

[JOJOforshaun]

@JOJOforshaun

Thanks for sharing this. I do not know the implications of this but if a script lacks @updateURL, @installURL, and @downloadurl - it will not be able to be updated currently, but perhaps this can be changed once I have a better understanding of this change from Greaseyfork.

Is there any more information on this? and why this is happening?

In fact, I'm not sure why this happened. But tampermonkey can update greasy fork user scripts.

[quoid]

@JOJOforshaun

If the user install a script through greaseyfork, internally we can save the installUrl and then use that to check for updates. It makes it harder and not sure why Greasefork is making this change either, but there are ways to work with it.

[JOJOforshaun]

@JOJOforshaun

如果用户通过greseyfork安装脚本，我们可以在内部保存installUrl，然后使用它来检查更新。这让事情变得更难，也不确定为什么Greasefork会做出这种改变，但有一些方法可以解决这个问题。

@JOJOforshaun

If the user install a script through greaseyfork, internally we can save the installUrl and then use that to check for updates. It makes it harder and not sure why Greasefork is making this change either, but there are ways to work with it.

https://stackoverflow.com/questions/38023717/

It is basically a very clear explanation here, which is analyzed from the perspective of historical reasons, update principles, best practices, etc.

[quoid]

It is basically a very clear explanation here, which is analyzed from the perspective of historical reasons, update principles, best practices, etc.

That is how @updateURL and @downloadURL is implemented currently. I am not sure how it is relevant to my comment above. Please elaborate.

[wolfissimo]

Is there any more information on this? and why this is happening?

As far as I understand, they strip @updateURL, @installURL, and @downloadurl to prevent the script to be updated from any URL outside of greasyfork.

[quoid]

I wonder if the change is prompted by security concerns or there is some other rationale.

[wolfissimo]

I think it's at least for two reasons.

1. Security: Prevent developers to offer a harmless script on the popular greasyfork platform and then install a malicious script via update from another server.
2. Commercial: Prevent developers to easily move their script from greasyfork to another userscript platform just via update.

[quoid]

Security: Prevent developers to offer a harmless script on the popular greasyfork platform and then install a malicious script via update from another server.

I like this idea and it seems like there is some enforcement when it comes to external libraries being used in a userscript, but I wonder if any other scanning is done to prevent any sort of personal data logging.

[ACTCD]

This issue will be resolved when #333 is completed.

[treyharris]

It isn’t clear to me how (or if) this is expected to work in userscripts that require editing (e.g. of constants for security keys, configuration when there’s no obvious way to present an in-browser UI, etc.).

I only upon reading this just now learned that—were things working like they were “supposed to”—the edits I’ve made to greasyfork scripts “should have been” overwritten, and only weren’t because greasyfork updating isn’t happening. (I’d naïvely assumed that I’d just been lucky so far that none of those scripts had been updated, and had been alert for effects showing my edits had been discarded.)

I had assumed I could get around this by, say, if the script had a GitHub repo, forking it, branching and making my local edits, installing it from my GitHub repo branch URL, then periodically pulling upstream updates and rebasing them into my branch. But now after reading the Stack Overflow description from above, I’m not sure. It sounds like that type of installation won’t be supported at all, and if I want a personally-edited userscript, I’d have to install it strictly from a file (presumably after removing all @…URL directives)?

Obviously, scripts requiring code edits for configuration are not ideal. But a lot of them exist. Whether that’s from script-author inexperience or laziness, no obvious interoperable way to persist configuration changes between browsers/hosts, or what, I don’t know.

[ACTCD]

@treyharris

Yes, if a user script has many personalization items, it should be stored in storage, not in script code. There is a set of APIs (GM.*Value) to help script writers with this task.

Anyway, if you need to maintain your own branched versions. You should also replace metadata such as the update/download URL with your own. Avoid automatic updates to the origin branch.

[treyharris]

Anyway, if you need to maintain your own branched versions. You should also replace metadata such as the update/download URL with your own. Avoid automatic updates to the origin branch.

Thanks, that makes sense.

But that’s also where I get entirely befuddled by the various .*URL$ metadata fields’ effects… If I do fork (or copy-paste) into, say, a personal GitHub repo, I can get a URL like https://raw.githubusercontent.com/treyharris/WK-Jitai-webfonts/customMods/jitai.user.js that will follow my customMods branch.

But which .*URL$ field(s) would I reset to reflect? All of them?

Like in this case, the only one currently included is:

https://github.com/treyharris/WK-Jitai-webfonts/blob/e282efe1f407dc7360b7a66e93ea491159c4aef0/jitai.user.js#L9:

// @homepageURL https://gist.github.com/obskyr/9f3c77cf6bf663792c6e

which isn’t a link to the script, but to its (Gist) repo—which contains two files, the JS and a Markdown readme. Would than mean changing this to something like

// @homepageURL https://github.com/treyharris/WK-Jitai-webfonts/tree/customMods

? And/or would I need to introduce new @updateURL and/or @downloadURL lines (which, I assume, would point directly at a raw file like https://raw.githubusercontent.com/treyharris/WK-Jitai-webfonts/customMods/jitai.user.js)?

[ACTCD]

@treyharris

In general, for automatic updating of scripts, most script managers use two pieces of meta information:

• @updateURL - a file containing only the metadata section of userjs to detect if a new version is available
• @downloadURL - download and update the full userjs from here if a new version is available

@updateURL may be optional in different extension implementations, so you can also write the same URL as @downloadURL to improve compatibility (if you don’t care about user traffic consumption) or just omit it.

Another case is that the above two URLs are both not included, in which case the script manager should detect and download updates directly from the installation URL. But currently this project does not support this method, which is what this issue needs to solve.

Other metadata, such as @supportURL and @homepageURL, have no effect on script updates. They are used to provide third-party script marketplaces or users, identifying your contact/feedback path. You don't have to add it if it's for your own use only.