Not found from machine user

Drone Support
1

Hello.

After add a machine user

drone user add test --machine

and trying to use from curl command, I’m receiving a 404 from the server

http POST https://drone.host/api/repos/<repo-org>/<repo-name>/builds Authorization:"Bearer <token received from add command>"
HTTP/1.1 404 Not Found

{
    "message": "Not Found"
}

From my personal user token it’s working fine.

):

2

If the repository is private, the machine account will not have access by default unless you create the machine user with admin privileges.

1 Like
3

You was right! Thanks

I was creating the user using both flags together (that gave me the wrong token) --machine --admin
But I needed to make two steps instead to work

This command generates an invalid token:

drone user add <username> --machine --admin

The correct way:

drone user add <username> --machine
drone user update <username> --admin

Thanks!

4

Wow, actually to create a build it doesn’t work at all for machine accounts (after update with admin flag) ):

It gives me:

{
    "message": "Bad credentials"
}
5

machine users cannot perform tasks that require an oauth2 tokens since they are not linked to actual github accounts, which includes activating a repository and creating a build.

There are some enhancements we could make to the build creation code so that a build can be created even by a machine account. Currently we assume the account creating the build has a github oauth2 token. This could be improved by not making the assumption, and instead always using the token of the repository owner (the individual that activated the repository).

3 Likes
6

Ran into this today. As it stands, non-admin machine users don’t seem to serve any purpose(?).

Kind of related, if Drone continues to operate as a OAuth app, it would be best to always use the token of the repository owner for all operations and also display the owner aka who activated the repository.

When the owner of a repo leaves an org we are sometimes left with a dangling repo because their token is no longer valid for repos in the org, but it’s a hunt to track down who it is and get someone else to chown the repo.

Having the owner name displayed would greatly help, or even being able to filter the list of repos by owner name.

Otherwise another approach after fiddling around with Circle CI is they seem to associate each repo with multiple users, so that as long as someone’s credential works, the GH API interaction is successful. This means they require each user who wishes to see that repo to “activate” it by adding it to their list of “watched repos”.

While it’s another step for the user when getting started, it does alleviate the “someone left the team and the repo stopped building” issue, since it will just use the next user’s token.

7

Having the owner name displayed would greatly help, or even being able to filter the list of repos by owner name.

Agreed, we need this

Otherwise another approach after fiddling around with Circle CI is they seem to associate each repo with multiple users, so that as long as someone ’s credential works, the GH API interaction is successful. This means they require each user who wishes to see that repo to “activate” it by adding it to their list of “watched repos”.

Moving from oauth2 to an GitHub application would resolve this issue since authorizations are tied to applications as opposed to individual users. This is one of two major benefits to GitHub applications, the second being reduced scope and repository access.

Ran into this today. As it stands, non-admin machine users don’t seem to serve any purpose(?).

We are using machine users for our autoscaler and for our reporting dashboard which is quite useful. They can be useful despite the fact they cannot activate repositories or create builds, however, as Brad mentioned the latter can be improved, likely with a simple code fix. Both would be resolved by moving from oauth2 to applications.

8

@tonglil just wanted to follow up that the create build API can now be used with machine users. This change is available in :latest and will be available in 1.8 which is planned for release this week.

We made the change the change described in my previous comment:

There are some enhancements we could make to the build creation code so that a build can be created even by a machine account. Currently we assume the account creating the build has a github oauth2 token. This could be improved by not making the assumption, and instead always using the token of the repository owner (the individual that activated the repository).