Move clientRelease url generator #460
Conversation
…a rate-limit of the github-api FAForever#418
| @@ -0,0 +1,54 @@ | |||
| import {Octokit} from "https://esm.sh/@octokit/core"; | |||
There was a problem hiding this comment.
Looks like this was not in the package, but directly downloaded. Why?
There was a problem hiding this comment.
Maybe you missed that this file is executed in a browser. Just used the recommended way for browsers.
There was a problem hiding this comment.
I guess the only potential discomfort I have here is about the presence of the script at the url and potential for injection.
Although to get around this we would have to use some bundler like vite or webpack correct
There was a problem hiding this comment.
even if we would have a builder, it will not change the potential harm.
if someone gets access to the repository (to any package we use), we can't do anything about it (forking and self-hosting would be an option), but since it's an official sdk from github, i don't have any discomfort.
there are other "security" issues looking into the code.
i would say, if we don't trust github or esm, we should also not trust cloudflare or google-tagmanager/analytics^^
The github client used in node was even more critical, since it could execute code in the container, this combined with node running as root and no checksum checks (already fixed with --frozen-lockfile option and the new Dockerfile) could have been more dramatic than just me ranting and creating a PR to fix that.
We also have to balance security, if the site would get compromised, they could only get a potential login-password, or impersonate FAF to trick the user to download/install/accept something that is not from us, if the browser-security is set to be wide open.
i would "trust" esm and github (maintainers of the repo), but maybe i am missing something here.
There was a problem hiding this comment.
I did not realize it was a github official sdk
There was a problem hiding this comment.
Was also surprised by the name
There was a problem hiding this comment.
My main concern would just be that if someone exceeds the GitHub API rate limit then this would fail when querying for the latest but with the fallback that should be handled I believe and it is run client side so won't affect the server.
I would also add /latest to the fallback url so that the user is taken directly to the latest release.
|
good point with the latest, i'll change this. |
|
since we are only hitting the github-api on click, we should not be the origin of a rate-limit (if not a developer and clicking the button multiple times^^). |
closes #418