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

Dynamic authorization tokens #167

Open
ari-becker opened this issue May 11, 2023 · 4 comments
Open

Dynamic authorization tokens #167

ari-becker opened this issue May 11, 2023 · 4 comments
Labels
enhancement New feature or request hacktoberfest

Comments

@ari-becker
Copy link

🚀 Feature Proposal

Currently, TURBO_TOKEN is defined as an environment variable, therefore making changes to the token(s) requires a full restart. Instead, authorized tokens should be stored in a database, and a UI or API should be exposed to add or remove tokens from that database; ideally allowing users some kind of SSO login flow which ends in issuing them a token.

Motivation

We're looking at alternatives to Vercel hosting the Turbo remote cache, because Vercel charges $20/user/month. If we do pay Vercel $20/user/month, then each user gets their own API token, and removing a user from Vercel also invalidates their access to the cache. We'd like to self-host the cache, but manually maintaining a list of tokens is an operational headache we'd like to avoid. If we were to decide to restrict ourselves to use only one API token (and share that API token via 1Password etc.), then we might as well make a shared Vercel user on Vercel's free tier for that purpose.

@fox1t
Copy link
Collaborator

fox1t commented May 15, 2023

I like this proposal. I wouldn't say I like adding a DB. It could be an optional DB, though. I also like the idea of having a UI.

@fox1t fox1t added the enhancement New feature or request label May 15, 2023
@lukeshay
Copy link

Maybe TURBO_TOKEN token could be updated to handle a comma-separated list of tokens. E.g. TURBO_TOKEN=token1,token2,token3. That way no DB is required and you can add/remove multiple tokens.

@ari-becker
Copy link
Author

I ended up switching companies, but the way we planned around this limitation was, instead of running a turborepo-remote-cache from a central location (thus prompting the whole question of a shared token vs. multiple tokens), instead we planned to run turborepo-remote-cache locally, a separate copy on each dev laptop + instantiate at runtime in CI, with a shared storage provider (e.g. S3). Thus each developer would be responsible for providing personal credentials, and CI would use CI's credentials, to connect to the same S3 bucket, for example.

@slongdotexe
Copy link

I thought I would add to this issue as having more control over verification of a user's Authorization token is somehing I'm very interested in. I can also see that some down-stream projects like cdk-turborepo-remote-cache have identified this as an area for potential improvement.

One approach for this that I think would allow developers or package maintainers this flexibility, is to let a consumer pass in a custom handler function for verifying the Auth token. From what I can tell, this could be achieved like so:

  • Abstract the existing token verificaiton code to a defaultAuthoizationHandler function.
  • Update createApp to accept a remoteCacheOptions object, with an authorizationHandler key, with the above. function as a default.
  • Pass remoteCacheOptions to turboRemoteCache.
  • Update documentation with examples of how to implement this, possibly under an 'Advanced Usage' section, with code snippets etc.

I'm interested in implementing this feature but it would be nice to have some feedback on the suggested approach or any other considerations first (:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request hacktoberfest
Projects
None yet
Development

No branches or pull requests

5 participants