API doesn't show private user repos for non admins and non owner users having read access #4158

New Issue

GiteaMirror · 2025-11-02T05:40:43-06:00

GiteaMirror commented

2025-11-02 05:40:43 -06:00

Originally created by @7FM on GitHub (Oct 21, 2019).

Gitea version (or commit ref): 1.9.4 built with GNU Make 4.1, go1.12.10 : bindata, sqlite, sqlite_unlock_notify
Git version: 2.20.1
Operating system: Debian Buster
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (see below)
- No
- Not relevant

Description

The API only returns private repos if you are the owner or administrator regardless if you have read access. This issue occurred a while ago with organizations too, but this was fixed. The problem remains for private user repos.

##Example:
How to reproduce:

Create User A
Create User B (non-admin)
Let User A create a private repository
Add User B as collaborator with read permission
Use user api: https://try.gitea.io/api/v1/users/userA_api_bug/repos
while beeing logged in as User B
Expected: Show private repo of User A because User B has read access

User B request via token:
curl -X GET "https://try.gitea.io/api/v1/users/userA_api_bug/repos" -H "accept: application/json" -H "authorization: token c96aed5997df331c976fc935e49cede48a96ff9f"

Expected same output as with user A via token:
curl -s -X GET "https://try.gitea.io/api/v1/users/userA_api_bug/repos" -H "accept: application/json" -H "authorization: token d459b6f9ceffa93af7a8cdfb36e82fe3d8f68b94"

Originally created by @7FM on GitHub (Oct 21, 2019).   - Gitea version (or commit ref): 1.9.4 built with GNU Make 4.1, go1.12.10 : bindata, sqlite, sqlite_unlock_notify - Git version: 2.20.1 - Operating system: Debian Buster - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [x] Yes (see below) - [ ] No - [ ] Not relevant ## Description The API only returns private repos if you are the owner or administrator regardless if you have read access. This issue occurred a while ago with organizations too, but this was fixed. The problem remains for private user repos. ##Example: How to reproduce: 1. Create User A 2. Create User B (non-admin) 3. Let User A create a private repository 4. Add User B as collaborator with read permission 5. Use user api: https://try.gitea.io/api/v1/users/userA_api_bug/repos while beeing logged in as User B Expected: Show private repo of User A because User B has read access User B request via token: curl -X GET "https://try.gitea.io/api/v1/users/userA_api_bug/repos" -H "accept: application/json" -H "authorization: token c96aed5997df331c976fc935e49cede48a96ff9f" Expected same output as with user A via token: curl -s -X GET "https://try.gitea.io/api/v1/users/userA_api_bug/repos" -H "accept: application/json" -H "authorization: token d459b6f9ceffa93af7a8cdfb36e82fe3d8f68b94"

GiteaMirror added the type/feature modifies/api labels 2025-11-02 05:40:43 -06:00

GiteaMirror closed this issue

2025-11-02 05:40:43 -06:00

GiteaMirror commented

2025-11-02 05:40:43 -06:00

@zeripath commented on GitHub (Oct 21, 2019):

So /repos/search would allow you to see these and you could set the owner to usera in the query. (In fact this is the Api the main web site uses.)

I'm not sure if we should change /users/username/repos to do the more complex permission checks that this adjustment needs - I guess it would simplify the code as we could just push it's implementation to that of /repos/search.

@zeripath commented on GitHub (Oct 21, 2019): So /repos/search would allow you to see these and you could set the owner to usera in the query. (In fact this is the Api the main web site uses.) I'm not sure if we should change /users/username/repos to do the more complex permission checks that this adjustment needs - I guess it would simplify the code as we could just push it's implementation to that of /repos/search.

GiteaMirror commented

2025-11-02 05:40:43 -06:00

@7FM commented on GitHub (Oct 21, 2019):

Not sure if a change would be that complex. I mean it was fixed for orgs/org/repos here: https://github.com/go-gitea/gitea/issues/5310
Also the jenkins gitea plugin and probably other projects too use this API because it is convenient.
You might have a look at my PR this might already fix this issue, which I cant really evaluate right now because of missing insights into gitea and testing.

@7FM commented on GitHub (Oct 21, 2019): Not sure if a change would be that complex. I mean it was fixed for orgs/org/repos here: https://github.com/go-gitea/gitea/issues/5310 Also the jenkins gitea plugin and probably other projects too use this API because it is convenient. You might have a look at my PR this might already fix this issue, which I cant really evaluate right now because of missing insights into gitea and testing.

GiteaMirror commented

2025-11-02 05:40:44 -06:00

@zeripath commented on GitHub (Oct 22, 2019):

Ah I see. I had missed that the underlying code was changed.

I suspect that the code in /repos/search is probably more efficient as you only grab the repositories that you have access to, but that can be fixed at a later point.

@zeripath commented on GitHub (Oct 22, 2019): Ah I see. I had missed that the underlying code was changed. I suspect that the code in /repos/search is probably more efficient as you only grab the repositories that you have access to, but that can be fixed at a later point.

GiteaMirror referenced this issue

2025-11-02 06:02:22 -06:00

[Feature] Migration/mirror from subversion (svn) #4769

GiteaMirror referenced this issue

2025-11-02 07:05:59 -06:00

Discussion of v1.15.x Roadmap #6766

Sign in to join this conversation.