Project

General

Profile

Injecting scripts without downloading them

Added by koszko about 2 years ago

For scripts with URL and SHA256 sum stored in the settings, would it make sense to inject them as <script> with src attribute instead of downloading with AJAX?

Cons:

  • more burden on Hydrilla as users' browsers will re-download scripts from time to time (can be mitigated if people set up mirrors)
  • users' higher reliance on centralized servers providing scripts

Pros:

  • lower complexity of Hachette - we won't need to care about [1] and [2] as browser will do it for us

What do you think?

[1] https://hachettebugs.koszko.org/issues/1 - "parallelize fetching of remote scripts"
[2] https://hachettebugs.koszko.org/issues/4 - "make it possible to cache remote scripts"

EDIT: Perhaps all cons can be mitigated if user sets up a private mirror on localhost (we can develop Hydrilla to be able to function as a mirror or caching proxy for another Hydrilla instance). We then only need some way to allow scripts from http://localhost:*port* to execute on HTTPS sites


Replies (5)

RE: Injecting scripts without downloading them - Added by jahoti about 2 years ago

I think it would be a great idea, especially given the mirror suggestion you provide (it wouldn't be too hard to enable mirrors over HTTPS in any case).

That said, I'm somewhat confused as to how this would/could put burden on Hydrilla. Aren't scripts served by Hydrilla downloaded using the text key?

RE: Injecting scripts without downloading them - Added by koszko about 2 years ago

it wouldn't be too hard to enable mirrors over HTTPS in any case

Depends for whom. Developing this should be easy, but if a user decides to set up a mirror on localhost, at least a self-signed cert would need to be created and imported into the browser. This can probably be automated when using a package manager, though (sorry, Losedows useds).

That said, I'm somewhat confused as to how this would/could put burden on Hydrilla.

I silently assumed browser's own caching mechanisms would result in more re-downloads than if a proper Hydrilla-aware caching of scripts was in place. I might be wrong :)

RE: Injecting scripts without downloading them - Added by jahoti about 2 years ago

it wouldn't be too hard to enable mirrors over HTTPS in any case
Depends for whom. Developing this should be easy, but if a user decides to set up a mirror on localhost, at least a self-signed cert would need to be created and imported into the browser. This can probably be automated when using a package manager, though (sorry, Losedows useds).

Somehow that fact managed to slip my mind despite the fact that I've been thinking about certificates quite regularly in the past few days (as part of a potential testing system).

In any case, if Microsoft ships the tools to generate self-signed certs, I expect that would make enabling HTTPS reasonably doable. Would there be any significant group of people who want to set up a local proxy yet couldn't (with some searching) determine how to deal with the certificates, regardless of OS?

That said, I'm somewhat confused as to how this would/could put burden on Hydrilla.
I silently assumed browser's own caching mechanisms would result in more re-downloads than if a proper Hydrilla-aware caching of scripts was in place. I might be wrong :)

You're definitely right about that! The point of confusion, which I now realize I never actually stated, was to do with it affecting Hydrilla; aren't scripts served by Hydrilla copied locally anyway, leaving only scripts from external sources specified by hash and url?

RE: Injecting scripts without downloading them - Added by koszko about 2 years ago

In any case, if Microsoft ships the tools to generate self-signed certs, I expect that would make enabling HTTPS reasonably doable.

We don't need M$' tools for this. I've been able to use Wine and MinGW to develop Windows programs in the past using only libre software. And even linked with OpenSSL ^
I am also looking forward to be able to do the same for Crapple macOS using Darling.

Would there be any significant group of people who want to set up a local proxy yet couldn't (with some searching) determine how to deal with the certificates, regardless of OS?

If we want to make it a viable solution to the issues mentioned, we need to make the biggest possible subset of our users want to set it up.
Most computer users and even many IT students are completely unaware of what certificates are. While learning about it is possible, it is not possible in a short time (~3 mins a user expects to spend installing stuff). If this is to be a viable solution, we need to automate everything. Also, if we don't, we might look unprofessional :/

That said, I'm somewhat confused as to how this would/could put burden on Hydrilla.
I silently assumed browser's own caching mechanisms would result in more re-downloads than if a proper Hydrilla-aware caching of scripts was in place. I might be wrong :)

You're definitely right about that! The point of confusion, which I now realize I never actually stated, was to do with it affecting Hydrilla; aren't scripts served by Hydrilla copied locally anyway, leaving only scripts from external sources specified by hash and url?

No. The way I wrote Hydrilla it assumes (unlike Hachette) that the scripts are (1) never referenced from external sources (except approved mirrors) and yet are (2) always served by hash and url. Why so? (1) because we don't want to rely on third-party servers but rather server the same thing ourselves and (2) because this is more flexible. We'll add a "pull source" button in the settings which will enable the user to get a copy anyway. And once we come to serve various versions of the same script (minified, non-minified, map) we won't be wasting bandwidth by sending the source together with the actual settings. Plus it was simply easier for me to program this way because I could leave the work of serving script files to Apache :p

I actually assumed Hydrilla would only inform the clients about a path to script resource (e.g. "somedir/somefile.js") and that path would then work when appended to any of the mirrors of that repository (e.g. "https://hydrilla-repo1.org/content/somedir/somefile.js" and "https://hydrilla-repo-service.org/mirror-of-koszko_org/content/somedir/somefile.js". We could then even separate the API server from actual mirrors ^

RE: Injecting scripts without downloading them - Added by jahoti about 2 years ago

No. The way I wrote Hydrilla it assumes [...]

That makes sense! All your other points follow then, I think, except that most computer users and IT students have no idea what certificates are- which unfortunately I don't disagree with you about :/.

Plus it was simply easier for me to program this way because I could leave the work of serving script files to Apache :p

LOL- don't change that!

    (1-5/5)