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

Support GitHub Private Repositories sync integration #521

Open
Tracked by #520
ACTCD opened this issue Jul 29, 2023 · 3 comments
Open
Tracked by #520

Support GitHub Private Repositories sync integration #521

ACTCD opened this issue Jul 29, 2023 · 3 comments
Labels
enhancement Feature work

Comments

@ACTCD
Copy link
Collaborator

ACTCD commented Jul 29, 2023

  • use generic URL scheme jump authorization method
  • synchronize user scripts from a specified repository path
  • store the authorization token in the system keychain (if feasible)
  • update strategy based on file hash or update time instead of metadata

Just to record some key points and ideas, no promises, no estimated time.

@peanball
Copy link

I would still add an option to declare bearer tokens into the script metadata. From a "load and install the script" perspective this is easier, but has potential security implications. For security's sake, there could also just be the indication for a prompt to add an auth token?

Regarding keychain: I'm reasonably certain that Firefox allows using the user's current auth state (including SSO cookies) available in the current browser window to be used for user script installation and possibly update. Safari is likely more stringent with what web extensions may do. The keychain sounds like a good and safe alternative.

@ACTCD
Copy link
Collaborator Author

ACTCD commented Jul 30, 2023

@peanball It looks like you are still stuck in the previous issue. Maybe it's just that I haven't articulated our vision clearly. If the feature is implemented as a separate integration, we need to consider more.

Instead of expecting the user to manually generate a token and fill it in somewhere, we should probably use the more common jump authorization login method to automatically complete the token passing. That is to say, the user will only see the GitHub standard authorization page, and click the button to complete the authorization.

To be more clear, this issue describes implementing more like a standalone GitHub Apps client, rather than achieving that through some tricky means, which is considered from the perspective of security and best practices.

That said, we won't consider sharing user page login status, we won't use URL formats that embed userinfo anywhere, and we won't let users manually add tokens to script metadata. etc. We want users to experience this integration easily and safely if we will provide it.

We will look forward to discussing and presenting ideas from such a perspective. Thanks.

@peanball
Copy link

I think it was more that I didn’t consider just GitHub, but other tools where you’d want to give access but not fully public URLs, e.g. some cloud storage, artefact repositories such as Artifactory, Nexus, etc. or other solutions like GitLab, BitBucket, etc.

That is out of scope for this issue though. For the GitHub case I have nothing to add at the moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Feature work
Projects
None yet
Development

No branches or pull requests

2 participants