API - list teams of an org with admin priviledges denied

[vakabus]

Hi,

I am trying to automate user registration and I've run into an issue, that I can't list teams of an organization without the authenticated user being in Owners of that org. Being an admin is ignored.

What I am doing:

1. logged in as an admin by using a token
2. list teams, get "users" team id (GET /orgs/{org}/teams)
3. add an user to team id from above (PUT /teams/{id}/members/{username})

What fails:

Step number 2 fails with this response:

{"message":"Must be an organization member","url":"https://godoc.org/github.com/go-gitea/go-sdk/gitea"}

Versions tested:

The same behavior was observed on version 1.7.2 as well as on version 1.8.0 (c5ec66a)

What was expected:

Because I am authenticated as an admin, I expected there wouldn't be such check. The API call should in my opinion pass and really return the list of teams.

Is there more correct way to add members to teams? The same thing I am trying to automate is possible via web UI. That's why I expected it to work. Or if this is the correct way, I think this check should be passed by being an administrator.

Thanks for any help!

[lunny]

Site admin cannot list organization's teams currently. Do you think @vakabus we should do that since organization' members could do that?

[vakabus]

Yeah, I would say, it should be possible. My line of reasoning would be as follows:

As far as I understood Gitea (I've been playing with it for only about 3 weeks now, please correct me if I am wrong), there are 3 types of users - site-admins, org-owners and normal users. Users are allowed to do anything they want within their profile and their personal repositories. Org-owners are allowed to do anything in their organization and in the organization's repositories. So following that, site-admins should be able to do anything on the whole site. I would say, that they should be in the same position as Unix root. There is nobody with higher permission (maybe except for root on the host system, but that doesn't count 😄).

That's why I would expect admin user to never be denied anything. I think, that every API call made by user with admin privileges should succeed (permission-wise). So specifically, listing teams by site-admins should be allowed.

If my arguments match Gitea's design, than yeah, I think it should be changed. Otherwise, I would love to know how it differs. Thank you!

[vakabus]

I found the permission checks in api.go file. Would a PR implementing the behavior described above be welcome? I am willing to give it a try. (I haven't wrote anything in Go yet). However, the more important question is whether this makes sense and whether it is an acceptable change.

[lafriks]

If we are talking about teams api than I don't see reason why site admin should not be able to do that, imho

[zeripath]

You can always use the Sudo header to change your effective user for the API calls.

[mmarif4u]

Is there any doc which list which API accept what headers? As of now, I can't see these headers in swagger.

[zeripath]

It's there in the authentication section. All of the API routes will accept either the Sudo header or the sudo query parameter.

[zeripath]

It's managed by this code here: https://github.com/go-gitea/gitea/blob/master/routers/api/v1/api.go#L80

I think better logging of sudoed actions is probably required, but I haven't really thought of a good way of doing it. I suspect Trace is too low a setting.

I think if we ever do add a become user option to the UI we should look again at how we log use actions. I suspect most logging should probably include the current & effective user name. I'll have a think.

[mmarif4u]

Thanks, @zeripath. My question was more generic for all APIs. That list is for all. I was thinking is there any API which accepts headers, if so they are not documented in swagger as far I know.

[zeripath]

Ah, no immediate other use of headers comes to mind. I remember the swagger documentation for the tokens API did say it returned it's values as headers at one point - it doesn't - but I think I fixed that.

[lunny]

@vakabus PRs are always welcome!

[vakabus]

@lunny Ok, I'll try to translate my ideas to code and documentation. It should not be that hard. :)

[vakabus]

Resolved by #6483. Thanks for the help.