API - list teams of an org with admin priviledges denied #3105

New Issue

GiteaMirror · 2025-11-02T05:00:52-06:00

GiteaMirror commented

2025-11-02 05:00:52 -06:00

Originally created by @vakabus on GitHub (Mar 26, 2019).

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:

logged in as an admin by using a token
list teams, get "users" team id (GET /orgs/{org}/teams)
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!

Originally created by @vakabus on GitHub (Mar 26, 2019). 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: ```json {"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!

GiteaMirror added the type/enhancement label 2025-11-02 05:00:52 -06:00

GiteaMirror closed this issue

2025-11-02 05:00:52 -06:00

GiteaMirror commented

2025-11-02 05:00:52 -06:00

@lunny commented on GitHub (Mar 26, 2019):

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

@lunny commented on GitHub (Mar 26, 2019): Site admin cannot list organization's teams currently. Do you think @vakabus we should do that since organization' members could do that?

GiteaMirror commented

2025-11-02 05:00:53 -06:00

@vakabus commented on GitHub (Mar 26, 2019):

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 commented on GitHub (Mar 26, 2019): 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 :smile:). 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!

GiteaMirror commented

2025-11-02 05:00:53 -06:00

@vakabus commented on GitHub (Mar 26, 2019):

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.

@vakabus commented on GitHub (Mar 26, 2019): I found the permission checks in [api.go](https://github.com/go-gitea/gitea/blob/master/routers/api/v1/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.

GiteaMirror commented

2025-11-02 05:00:53 -06:00

@lafriks commented on GitHub (Mar 26, 2019):

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

@lafriks commented on GitHub (Mar 26, 2019): If we are talking about teams api than I don't see reason why site admin should not be able to do that, imho

GiteaMirror commented

2025-11-02 05:00:53 -06:00

@zeripath commented on GitHub (Mar 26, 2019):

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

@zeripath commented on GitHub (Mar 26, 2019): You can always use the Sudo header to change your effective user for the API calls.

GiteaMirror commented

2025-11-02 05:00:53 -06:00

@mmarif4u commented on GitHub (Mar 27, 2019):

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

@mmarif4u commented on GitHub (Mar 27, 2019): Is there any doc which list which API accept what headers? As of now, I can't see these headers in swagger.

GiteaMirror commented

2025-11-02 05:00:54 -06:00

@zeripath commented on GitHub (Mar 27, 2019):

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

@zeripath commented on GitHub (Mar 27, 2019): It's there in the authentication section. All of the API routes will accept either the Sudo header or the sudo query parameter.

GiteaMirror commented

2025-11-02 05:00:54 -06:00

@zeripath commented on GitHub (Mar 27, 2019):

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.

@zeripath commented on GitHub (Mar 27, 2019): 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.

GiteaMirror commented

2025-11-02 05:00:54 -06:00

@mmarif4u commented on GitHub (Mar 27, 2019):

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.

@mmarif4u commented on GitHub (Mar 27, 2019): 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.

GiteaMirror commented

2025-11-02 05:00:54 -06:00

@zeripath commented on GitHub (Mar 27, 2019):

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.

@zeripath commented on GitHub (Mar 27, 2019): 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.

GiteaMirror commented

2025-11-02 05:00:55 -06:00

@lunny commented on GitHub (Mar 27, 2019):

@vakabus PRs are always welcome!

@lunny commented on GitHub (Mar 27, 2019): @vakabus PRs are always welcome!

GiteaMirror commented

2025-11-02 05:00:55 -06:00

@vakabus commented on GitHub (Mar 28, 2019):

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

@vakabus commented on GitHub (Mar 28, 2019): @lunny Ok, I'll try to translate my ideas to code and documentation. It should not be that hard. :)

GiteaMirror commented

2025-11-02 05:00:55 -06:00