API returns 201 even though not all data from the request has been processed due to the sudo user not beeing an andministrator #5359

New Issue

GiteaMirror · 2025-11-02T06:22:33-06:00

GiteaMirror commented

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

Originally created by @PascalMinder on GitHub (May 7, 2020).

Gitea version (or commit ref):
Git version: 1.12.0+dev-264-ga104864da
Operating system: Windows
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

Description

I'am currently in the process of migrating Trac issues to a new Gitea instance. For this reason I am currently working on a php script which reads issues from the Trac database and creates them over the Gitea API on the new gitea instance.

To create the issue in the name of the orginal author I use the "sudo" header with the user which created the issue in Trac (with a mapping table).

When I try to create an Issue with a user which is not an administrator I get a 201 http back and the issue gets created. BUT linked labels or milestones are not createt for the issue. However if the user is an administrator no such error occures and the issue gets created with all linked labels and milestones.

I would have expected, that the api returns a 400 http header or something similar if not all data could be processed. Is this an intended behaviour?

Originally created by @PascalMinder on GitHub (May 7, 2020). - Gitea version (or commit ref): - Git version: 1.12.0+dev-264-ga104864da - Operating system: Windows - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [ ] Not relevant - Log gist: ## Description I'am currently in the process of migrating Trac issues to a new Gitea instance. For this reason I am currently working on a php script which reads issues from the Trac database and creates them over the Gitea API on the new gitea instance. To create the issue in the name of the orginal author I use the "sudo" header with the user which created the issue in Trac (with a mapping table). When I try to create an Issue with a user which is not an administrator I get a 201 http back and the issue gets created. BUT linked labels or milestones are not createt for the issue. However if the user is an administrator no such error occures and the issue gets created with all linked labels and milestones. I would have expected, that the api returns a 400 http header or something similar if not all data could be processed. Is this an intended behaviour?

GiteaMirror added the issue/confirmed modifies/api labels 2025-11-02 06:22:33 -06:00

GiteaMirror commented

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

@6543 commented on GitHub (May 7, 2020):

this is not intended behaviour

@6543 commented on GitHub (May 7, 2020): this is not intended behaviour

GiteaMirror commented

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

@6543 commented on GitHub (May 7, 2020):

and if you have a working script it would be nice to publish it somewhere - could go on the list of #8689

@6543 commented on GitHub (May 7, 2020): and if you have a working script it would be nice to publish it somewhere - could go on the list of #8689

GiteaMirror commented

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

@6543 commented on GitHub (May 7, 2020):

I'll have a look at this but it would be nice if you can describe what exactly do you mean with "linked" labels

@6543 commented on GitHub (May 7, 2020): I'll have a look at this but it would be nice if you can describe what exactly do you mean with "linked" labels

GiteaMirror commented

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

@PascalMinder commented on GitHub (May 7, 2020):

So on the page https://try.gitea.io/api/swagger#/issue/issueCreateIssue it says, the json below can be used to create a new issue. There is a field labels and a field milestone. Both of them accept a int value to like one (milestone) or multiple labels. If I use sudo (with an administrator) all works as expected and the new issue has the right labels linked. But if the sudo user is not an administrator the issue gets created but is not linked.

{
  "assignee": "string",
  "assignees": [
    "string"
  ],
  "body": "string",
  "closed": true,
  "due_date": "2020-05-07T07:40:49.100Z",
  "labels": [
    0
  ],
  "milestone": 0,
  "title": "string"
}

The script has a big limitation, that there is no api which support setting the created_at value. This is a bit of an issue for a nice import.

@PascalMinder commented on GitHub (May 7, 2020): So on the page https://try.gitea.io/api/swagger#/issue/issueCreateIssue it says, the json below can be used to create a new issue. There is a field labels and a field milestone. Both of them accept a int value to like one (milestone) or multiple labels. If I use sudo (with an administrator) all works as expected and the new issue has the right labels linked. But if the sudo user is not an administrator the issue gets created but is not linked. ``` { "assignee": "string", "assignees": [ "string" ], "body": "string", "closed": true, "due_date": "2020-05-07T07:40:49.100Z", "labels": [ 0 ], "milestone": 0, "title": "string" } ``` The script has a big limitation, that there is no api which support setting the created_at value. This is a bit of an issue for a nice import.

GiteaMirror commented

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

@zeripath commented on GitHub (May 8, 2020):

I don't like the idea of arbitrary users creating things in the past, future or whenever. It seems like we would be better off creating a proper migration from trac instead.

@zeripath commented on GitHub (May 8, 2020): I don't like the idea of arbitrary users creating things in the past, future or whenever. It seems like we would be better off creating a proper migration from trac instead.

GiteaMirror commented

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

@PascalMinder commented on GitHub (May 8, 2020):

Yeah that would probably be the better way.

@PascalMinder commented on GitHub (May 8, 2020): Yeah that would probably be the better way.

GiteaMirror commented

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

@6543 commented on GitHub (May 9, 2020):

@PascalMinder the API is working fine, this is because of securety conzernes too
since with sudo you act with the same permission as the user you put into sudo, and if this user is not alowed to add labels API should not allow this too

so this issue is infalid

@PascalMinder for you: your script has to create the issue first and the admin acount should add labels and milestones afterwards

@6543 commented on GitHub (May 9, 2020): @PascalMinder the API is working fine, this is because of securety conzernes too since with sudo you act with the same permission as the user you put into sudo, and if this user is not alowed to add labels API should not allow this too so this issue is **infalid** @PascalMinder for you: your script has to create the issue first and the admin acount should add labels and milestones afterwards

GiteaMirror commented

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

@PascalMinder commented on GitHub (May 9, 2020):

@6543 Okay, but if there is a security concern about a user which adds a label with sudo, the API should probably return another status code than 20X and not apply half of the requested changes?

@PascalMinder commented on GitHub (May 9, 2020): @6543 Okay, but if there is a security concern about a user which adds a label with sudo, the API should probably return another status code than 20X and not apply half of the requested changes?

GiteaMirror commented

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

@6543 commented on GitHub (May 9, 2020):

the API function's itself do not know if the user is introduced by sudo or if he acts itself with the api

@6543 commented on GitHub (May 9, 2020): the API function's itself do not know if the user is introduced by sudo or if he acts itself with the api

GiteaMirror commented

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

@6543 commented on GitHub (May 9, 2020):

Instead of silent droping we could return a 422 ... but It will be a breaking change ...

@6543 commented on GitHub (May 9, 2020): Instead of silent droping we could return a 422 ... but It will be a breaking change ...

GiteaMirror commented

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

@stale[bot] commented on GitHub (Jul 11, 2020):

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

@stale[bot] commented on GitHub (Jul 11, 2020): This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

GiteaMirror commented

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

@6543 commented on GitHub (Jul 11, 2020):

ping

@6543 commented on GitHub (Jul 11, 2020): ping

GiteaMirror referenced this issue

2025-11-02 15:36:39 -06:00

[PR #5362] [MERGED] app.ini.sample: add ENABLE_USER_HEATMAP default config #17766

Sign in to join this conversation.