plugin-update-checker
plugin-update-checker copied to clipboard
YahnisElsts
Would like to use a GitLab repo-read_only token, not my personal access token
Rather than a user-level read/write api token, I would prefer to use a token that is specific to a single repo, and only has read access. I can create a token like that in gitlab, but it won't work in the updater.
I'd rather not share my read/write token with all the wordpress plugins that I may distribute. Is this something that could be added in? Or there a way to make that work currently?
That is currently not possible. I would be okay with adding something like that, but I don't have the time to do that myself right now.
When you say that you can create a token like that, are you referring to deploy tokens? If I'm reading the GitLab docs correctly, these tokens can only be used with git and not the GitLab API. Does this mean the update checker would have to execute git commands?
I was seeing the same thing myself... yes I mean "deploy tokens". And yes it looks like they don't currently have access to the gitlab api. I thought the update checker could just use the deploy token to access the zip file from gitlab. But maybe not, maybe it would have to actually execute git.
Perhaps I'm overlooking something: my only goal is for the PUC, as baked into my plugin, to be able to get an updated version from a private GitLab repo, and have my personal read/write token not in the code. Looking at GitLab, it doesn't look like they offer any read-only API access.
Do you have a recommendation for setting up the PUC to be able to do this, but without giving away my personal GitLab read/write token?
Sorry, I don't know of any existing solutions.
A while ago I was thinking of building a kind of an "update proxy" that would pull update information from private repositories and then present it as JSON. This way you would only have to share an API token with one service instead of every user. Also, it would make it possible to add more advanced features like usage stats, license keys, gradual rollout, etc. I didn't pursue that idea because I wasn't sure if anyone actually needed something like that. What do you think?
So basically my own private alternative to the WordPress plugins directory that I could host on my own site specifically for the plugins I build? I think it's a great idea and I would definitely use it. My use case is that I make plugins and sell them. But I'd like to be able to push out updates to those plugins. Because I sell them, I can't put them on the Wordpress plugin directory, so there's no way to inform client sites that a purchased plugin has an update.
Something like that, though I would prefer to make it a paid service or product.
In case you didn't know, I already have an update server project. However, it's pretty basic and doesn't support GitLab (or any other VCS).
@jakeparis Perhaps you're already aware of this (and it doesn't meet all your requirements) but you can also create separate 'machine user' accounts and then add them as collaborators to your private repo. ...this way they only have access to the one repo and not all your repos. If you have an organisation account, you can then also set more granular access for collaborators - I believe restricting to read only, but can't be sure.. I don't have teams account. While it does not hide your access token it does mean you can deploy your plugin using the machine user access token which only has access to the one repo - this is what i've done until i find a better solution
This method is actually suggested by github
https://docs.github.com/en/developers/overview/managing-deploy-keys#machine-users
@jakeparis Perhaps you're already aware of this (and it doesn't meet all your requirements) but you can also create separate 'machine user' accounts and then add them as collaborators to your private repo. ...this way they only have access to the one repo and not all your repos. If you have an organisation account, you can then also set more granular access for collaborators - I believe restricting to read only, but can't be sure.. I don't have teams account. While it does not hide your access token it does mean you can deploy your plugin using the machine user access token which only has access to the one repo - this is what i've done until i find a better solution
This method is actually suggested by github
https://developer.github.com/v3/guides/managing-deploy-keys/#machine-users
Your link does not seem to redirect right. Here you go again: https://developer.github.com/v3/guides/managing-deploy-keys/#machine-users
This workaround has been our strategy as well. To bad there isn't something like a project token or something. Or group token for that sake.
