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

Private remote_files #106

Closed
pbrisbin opened this issue Jun 4, 2020 · 0 comments
Closed

Private remote_files #106

pbrisbin opened this issue Jun 4, 2020 · 0 comments

Comments

@pbrisbin
Copy link
Member

pbrisbin commented Jun 4, 2020

Context

In .restyler.yaml, we support remote_files to define files to download before starting, so you can centralize any auto-formatter configuration. These files need to be publicly accessible (e.g. as a raw. URL on a public GitHub repository).

Feature

Support remote_files that are private if they're in a GitHub repository accessible to our App installation.

Limitations

  • You would have to be accessing files in a private GitHub repository, not just anything that requires some form of authentication
  • You would have to have Restyled installed in a way that allows access to that repository too, either by installing for all, or by including that repository explicitly

Question: how do we surface these limitations clearly if user's experience errors because of them?

Implementation ideas

Restyler has an installation access token it uses for cloning and interacting with the API. Raw files in private repositories are accessible by appending ?token= to their URLs. We could append our token to remote_files[].url when required.

1- Interpolate our access token anywhere we see ${SOMETHING} in the URL

This puts URL construction in the user's hands and so is a more flexible base on which to build this feature. However, since we only support one very specific private source, there'd be no reason to use this flexibility and it would just introduce a place for the user to get something wrong. And, even if we build out support for other private sources, interpolating our GitHub access token into the URL in some other format wouldn't make sense.

2- Support a new private: true|false key

If true, append ?token=... ourselves. This is the best user experience, but is slightly more complex, since we'd should not naively append, but rather parse-append-rebuild, uri-encode, etc, etc. Libraries should make this easy, but it does introduce a new point of failure in handling remote files.

Additional information

Whatever we do here, we should have a consistent behavior for #96.

@pbrisbin pbrisbin moved this to Icebox in Roadmap Mar 6, 2023
@pbrisbin pbrisbin added this to Roadmap Mar 6, 2023
@github-project-automation github-project-automation bot moved this from 🧊 Icebox to ✅ Done in Roadmap Jul 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Status: Done
Development

No branches or pull requests

1 participant