-
Notifications
You must be signed in to change notification settings - Fork 44
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 for Private Repositories #13
Comments
Apparently the way to do this is using either Personal Tokens or Applications (in Github settings). References
Tutorials/stuff on the net
|
I'll have to read into all the above, thanks @diegogangl. From your understanding, any thoughts on how to best keep the tokens private while still needing access from within a publicly distributed codebase? e.g. allow anyone with a copy to download updates from a private repo. |
Indeed thanks @diegogangl. My guess as a potential direction to take, similar to how the blender institute's addon is shared with a compiled pyc file, it might be necessary (or at least advisable) for developers to distribute the addon with the compiled code only and safely store the SECRET KEY in the pyc module. Otherwise, of course everything would ultimately be exposed in plain text code anyways. That being said, would still need to be careful and see if restrictions can be locked onto a key. E.g. you wouldn't want someone to use the addon as a way to hack into a repo and have things like write or delete privileges. The OAuth 2.0 looks like the direction that should be taken, over having personal access keys and certainly the most basic auth method, but nonetheless the above statement would still apply around concealing the secret. I need to understand how to control OAuth restrictions better too. |
Update: I have 80% implemented accessing private repositories for Gitlab and will be exploring similar methods for Github and bitbucket. The way it works now for gitlab is a user can create a personal token, define it to only work/support the api access (as opposed to other permissions like write etc), and this token is added in the header of requests to the private repo with success. This setup would likely vary depending on the "engine" or service used, but could be made to be configured as a part of the engine code setup itself to be generic and consistent on how to set it up between the different services. |
Support for GitLab private repos has existed for a little while now, but to put it explicitly, here's a status on the implementation:
Will be revisiting |
Hey everyone! Any updates regarding Github private repo support? |
Updated status on private repo implementation, via @TheDuckCow
See below for details
The text was updated successfully, but these errors were encountered: