Skip to content
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

Enhance meta.js detection/support #1885

Closed
arantius opened this issue Mar 3, 2014 · 7 comments
Closed

Enhance meta.js detection/support #1885

arantius opened this issue Mar 3, 2014 · 7 comments
Milestone

Comments

@arantius
Copy link
Collaborator

arantius commented Mar 3, 2014

See also #1884.

Greasemonkey has special support for the "userscripts.org" domain and will check for updates via their "meta.js" convention, rather than downloading the whole script.

This mechanism could be extended to work across the whole internet. I'm imagining some sort of:

  1. Check for update, first time at meta.js. If we failed to find meta.js before, use normal download location.
  2. If found, just use it as normal, done.
  3. If (meta.js is) not found, record that fact and restart the process.
  4. If an update is found no matter what, reset the "meta.js found/not found" bit. To give authors a chance to add it later, i.e. if a script suddenly becomes popular.
@sizzlemctwizzle
Copy link
Contributor

I remember @erikvold suggesting this at some point. This can already be solved by setting @updateURL and @downloadURL to the proper urls. I'd also like to mention that #1824 supports this (assuming you can detect this custom accept value and serve up the .meta.js file). Seems like a lot of work for something that already has working solutions.

@arantius
Copy link
Collaborator Author

arantius commented Mar 3, 2014

At this point, we should definitely make it consistent for all scripts, regardless of hosting platform.

I, personally, have always disliked that download/update URL leaked into the metadata at all. It should have always been something invisible that "just works". It's hard to put that feeling into exact words, but probably: I as a user should be able to navigate to myfavoritescripthost.example.com/ and install scripts, and get updates only from that site, because I trust it. Not whatever random site got encoded into the metadata of that script, in any update from then on forever to the future.

Or maybe that's made up nonsense? Extensions allow these values to be set (which probably how it became a Greasemonke feature?), but they have better/more strict security checks around the serving of updates and signing of the extension, etc.

@sizzlemctwizzle
Copy link
Contributor

I, personally, have always disliked that download/update URL leaked into the metadata at all. It should have always been something invisible that "just works".

I put those keys in (or at least defined their behavior). The rationale was that it is only way to insure that a script can be installed from anywhere and still check/install updates from the right place. It can be invisible, since GM uses the install url for update checks and installing updates automatically.

Who is this proposed feature targeted at? People who host static scripts on their (https) site? I guess you remove the step of setting the download/update URLs. But is that really an improvement? If they set those values and posted their script to USO (or what ever site), then when any user installs that script (from what ever site) they will still receive updates from the official source.

I as a user should be able to navigate to myfavoritescripthost.example.com/ and install scripts, and get updates only from that site, because I trust it.

I trust who wrote the script and set the download/update URLs, and want to get updates from that author because I trust them.

Not whatever random site got encoded into the metadata of that script

Who does this?

(which probably how it became a Greasemonke feature?)

Nope. Total coincidence. Guess great minds think alike haha

but they have better/more strict security checks around the serving of updates and signing of the extension, etc.

Yes they do, but they need to. Malicious extensions can do far more harm than malicious user scripts. Still I wish there was a more secure way to handle this.

Anyway, I'm -0.5 on this. I'm not totally against it, but a little hesitant. If we do it, I think we must keep the existing metadata keys. The cat is already out of the bag.

@sizzlemctwizzle
Copy link
Contributor

Unrelated but I don't know where else to put it: OpenUserJS.org is now https-only, so you can update this page (I'd do it but I can't login for some reason).

@jerone
Copy link
Contributor

jerone commented Mar 4, 2014

Unrelated but I don't know where else to put it: OpenUserJS.org is now https-only, so you can update this page (I'd do it but I can't login for some reason).

Done!

@arantius
Copy link
Collaborator Author

arantius commented Mar 4, 2014

(I'd do it but I can't login for some reason).

Email me please. I'd like to make sure this works, and I'm not accidentally shutting the world off from updating the wiki. (Batttling spam on a wiki ....)

@sizzlemctwizzle
Copy link
Contributor

I'd like to make sure this works

It works. I just guessed the wrong password. Sorry for the inconvenience.

@arantius arantius added this to the 1.17 milestone Mar 21, 2014
@arantius arantius modified the milestones: 1.16, 1.17 Apr 30, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants