Add option to provide GitHub API token

[FachtalError]

Is your feature request related to a problem? Please describe.
With the latest changes to the GitHub API, one gets rate-limited ridiculously fast, 403ing any requests. This makes updating addons (or even checking for updates) a tedious gamble.

Describe the solution you'd like
Similar to TaimiHUD, having the option of generating and setting an API token would circumvent this problem, as even free logged-in users have a higher ratelimit on the API. This would be an optional feature with a fallback to current behaviour for empty (unset) or faulty token strings.
It might even be an idea of providing some way for addons to use the API token registered in Nexus, but I'm not sure if that is possible/smart.

Describe alternatives you've considered
The only alternative I personally could see is another git server that mirrors the addon repositories and isn't ratelimited. This is neither feasible nor smart.

Additional context
Sadly I lack both time and skill to provide the team with a PR implementing the API token.

[DeltaRaidcore]

Support for an environment variable will be added, but the default will be routing the downloads through raidcore.gg as the installation provider. (Addons will have to opt into this feature.)

[FachtalError]

I'm not sure using an envvar for secrets is a good idea, as scoping those properly, especially on Windows, is not trivial.
Wouldn't an entry in the options menu ingame be an all around better solution?
With "routing the downloads through raidcore.gg" I guess you mean mirroring the addon on the raidcore server in some capacity, guess that'll solve the issue for ppl, assuming addon makers opt in.

[DeltaRaidcore]

Using a plaintext config file for secrets is equally bad, but most developers have set up their tokens with environment variables and this also moves the responsibility to the user, not Nexus.

As for scoping them, I'm not sure what there is to consider to be frank, unless you have some elaborate setup with containerisation.

Regarding raidcore.gg as a provider, I will probably default this for all library hosted addons. But this is a matter I will discuss with addon developers directly first before rolling it out. There's a major update for Nexus coming and many of the changes are still pending.

[itsaw]

So, before anyone starts attacking me here, the simplest solution would probably be to turn our backs on GitHub and have Raidcore set up its own Git server. I personally use Forge.io, and there are plenty of options for CI/CD there, too—just a tip.

[FachtalError]

Using a plaintext config file for secrets is equally bad, but most developers have set up their tokens with environment variables and this also moves the responsibility to the user, not Nexus.

Personally I don't exactly see the difference, I'll need to read up on that distinction. My primary concern was usability I admit.

As for scoping them, I'm not sure what there is to consider to be frank, unless you have some elaborate setup with containerisation.

I'm a bit rusty on Windows, but scoping as in executing GH_TOKEN=xyz path-to-gw2-executable instead of a global envvar. Still leaves the plaintext token on-disk, but at least not permanently in-memory and easily readable by any process. Of course through wine/proton it scopes just fine, just not for the majority of people using Windows.

So, before anyone starts attacking me here, the simplest solution would probably be to turn our backs on GitHub and have Raidcore set up its own Git server. I personally use Forge.io, and there are plenty of options for CI/CD there, too—just a tip.

While I personally like the idea of not using GH (or GitLab), to really address the issue at hand you'd have to either get every addon dev to move from GH or to essentially mirror every single addon repository. Neither of those are realistic imho, hence me asking for the GH token option.

[DeltaRaidcore]

Scoping a token or environment variable is outside the scope of Nexus. Nexus runs in-process, not outside of it.
Self-hosting a Git instance is just not realistic. This is about addons not about Nexus itself.

[FachtalError]

Scoping a token or environment variable is outside the scope of Nexus. Nexus runs in-process, not outside of it.

I'm very much aware of the limitations and realistic scope of a hook DLL. Looking forward to the inclusion of whatever GH-Token functionality is coming, reckon you'll track that in this issue meaning closure of that means integration done and live.