At least t̶w̶o̶ three API calls don't work

[HoffmannP]

• Gitea version (or commit ref): bae2642
• Git version: 2.15.0
• Operating system: Alpine Linux 3.7
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL) see https://try.gitea.io/api/swagger
  • No
  • Not relevant
• Log gist: https://gist.github.com/HoffmannP/9f6ff51fe0168e1ad1195c3d1f89a431

Description

At least two API calls don't work:

• Getting a special commit (in my example the latest commit in a branch) via /repos/{owner}/{repo}/commits/{ref}/statuses

• Creating a release via /repos/{owner}/{repo}/releases

• Tested with newest Docker version

• Test with swagger command interface and from outside (using AuthToken)

[HoffmannP]

Seeme to me the log shows two completely different problems:

1. either the query is wrong or only searching for a SHA is supported
2. the POST is nevertheless seen as a GET-request

Can s/o confirm &&/|| fix this?

[HoffmannP]

Little code to test against try.gitea.io

read TOKEN
curl -s "https://try.gitea.io/api/v1/repos/gitea/gitea/branches" -H "Authorization: token $TOKEN" | jq ".[].name"
> … all branches …
curl -s "https://try.gitea.io/api/v1/repos/gitea/gitea/commits/HEAD/statuses" -H "Authorization: token $TOKEN"
> []
curl -s "https://try.gitea.io/api/v1/repos/gitea/gitea/commits/fa3ceb610d/statuses" -H "Authorization: token $TOKEN"
> []
curl -s "https://try.gitea.io/api/v1/repos/gitea/gitea/commits/fa3ceb610d579c64142321ad4c82398a9d0bfde0/statuses" -H "Authorization: token $TOKEN"
> []

[markuman]

Does GET /users/{username}/tokens and POST /users/{username}/tokens works for you? I got an empty response here on my own installation.

[HoffmannP]

I tried it and voilà

curl -s "$SERVER/api/v1/users/$USER/repos" -H "Authorization: token $TOKEN"
> … all repos …
curl -s "$SERVER/api/v1/users/$USER/tokens" -H "Authorization: token $TOKEN"
>    (empty)
curl -D - -s "$SERVER/api/v1/users/$USER/tokens" -H "Authorization: token $TOKEN"
> HTTP/1.1 401 Unauthorized
> …
> Content-Length: 0

So I also don't get a response (same for the POST request)

[markuman]

I like to reference to #4234 also

[markuman]

@stevegt as you've mentioned in #4243 it must be used token in the auth header

-H "Authorization: token 65eaa9c8ef52460d22a93307fe0aee76289dc675"

the result for listing tokens is the same, an empty array.

curl --request GET --url https://git.osuv.de/api/v1/users/m/tokens -H "accepts: application/json" -H 'Authorization: token acb123...'

[HoffmannP]

I'm confused, what do you guys think, is "Unauthorized" it a Gitea bug (a bug in the API) or just a missuse? I think the first b/c

1. I'm using the correct auth-tokken
2. I'm an admin user
   so -> I shouldn't be "Unauthorized"

[bkcsoft]

/users/:name/tokens is special and requires you to Authenticate using BasicAuth

gitea/routers/api/v1/api.go

Lines 302 to 306 in 85414d8

	m.Group("/tokens", func() {
	m.Combo("").Get(user.ListAccessTokens).
	Post(bind(api.CreateAccessTokenOption{}), user.CreateAccessToken)
	}, reqBasicAuth())
	})

Which is set here

gitea/modules/auth/auth.go

Lines 125 to 143 in 85414d8

	// Check with basic auth.
	baHead := ctx.Req.Header.Get("Authorization")
	if len(baHead) > 0 {
	auths := strings.Fields(baHead)
	if len(auths) == 2 && auths[0] == "Basic" {
	uname, passwd, _ := base.BasicAuthDecode(auths[1])
	u, err := models.UserSignIn(uname, passwd)
	if err != nil {
	if !models.IsErrUserNotExist(err) {
	log.Error(4, "UserSignIn: %v", err)
	}
	return nil, false
	}
	return u, true
	}
	}
	return nil, false

Also interested in knowing what status-code you get for /statuses 🙂

[markuman]

@bkcsoft hmm interesting. Indeed, listing only with basic auth work - even if this account is secured by 2FA.

$ curl --request GET --url https://m:[email protected]/api/v1/users/m/tokens
[{"name":"test","sha1":"..."},{"name":"dev","sha1":"..."}]

I also noticed that the {username} in the url specification /users/{username}/tokens is completely irrelevant.

$ curl --request GET --url https://m:[email protected]/api/v1/users/fasgdjfhgdsf/tokens
[{"name":"test","sha1":"..."},{"name":"dev","sha1":"..."}]
$

[kainz]

So I'm running gitea in a setup doing SSL client certificate authentication in a reverse proxy, and injecting that as a header for gitea to use. Needless to say, that breaks the tokens api totally.

I have a patch which hacks in detection for client cert auth as well as basic auth in this path, but the whole logic here seems not great. Any thoughts from gitea maintainers on seeing a rework for this? It seems there are some (expected?) differences to the regular authentication rules, but they aren't well codified. What should they be?

[techknowlogick]

Sidenote, in regards to 2FA, GitHub requires a header to be set with the rotating code in regards to requesting URLs with basic auth.

[HoffmannP]

I just wanted to report that v1.5 does not fix the API problems I reported initially:

1. can fetch all branches of a repo
2. can't fetch a commit's combined status, by branch/tag/commit reference
3. can't fetch commit status via sha (neither long nor short sha-form)

This is not an authorization problem!

Test:

> curl -s https://try.gitea.io/api/v1/repos/gitea/gitea/branches
(…works…)
> curl -s https://try.gitea.io/api/v1/repos/gitea/gitea/branches | jq -r '.[] | select(.name | match("release/v1.5")) | .commit.id'
cfe6941905de745aed1f9297d9717249f53e6e67
> curl -D - -s https://try.gitea.io/api/v1/repos/gitea/gitea/commits/release%2Fv1.5/statuses
(HTTP 200 - works but empty #branch)
> curl -D - -s https://try.gitea.io/api/v1/repos/gitea/gitea/commits/v1.5.0/statuses
(HTTP 200 - works but empty #tag)
> curl -D - -s https://try.gitea.io/api/v1/repos/gitea/gitea/commits/cfe6941905de745aed1f9297d9717249f53e6e67/statuses
(HTTP 200 - works but empty #commit)
> curl -D - -s https://try.gitea.io/api/v1/repos/gitea/gitea/commits/HEAD/statuses
(HTTP 200 - works but empty #bonus:reference)
> curl -D - -s https://try.gitea.io/api/v1/repos/gitea/gitea/statuses/cfe6941905de745aed1f9297d9717249f53e6e67
(HTTP 200 - works but empty #otherEndpoint)

Also, releasing still fails

> curl -D - -X POST "https://$server/api/v1/repos/{owner}/{repo}/releases" -H "accept: application/json" -H "Authorization: token $token" -H "Content-Type: application/json" -d "{ \"body\": \"This is just a test release\", \"draft\": true, \"name\": \"my test\", \"prerelease\": true, \"tag_name\": \"testing\", \"target_commitish\": \"$commit\"}"
HTTP/1.1 404 Not Found
Set-Cookie: lang=en-US; Path=/; Max-Age=2147483647
Set-Cookie: i_like_gitea=48de81100517a47c; Path=/; HttpOnly
Set-Cookie: _csrf=XFBcIQxaBl1YNe9qFTRmh0L8oUI6MTUzNDE3MjEyNzc1NDkwNzM4Nw%3D%3D; Path=/; Expires=Tue, 14 Aug 2018 14:55:27 GMT
X-Frame-Options: SAMEORIGIN
Date: Mon, 13 Aug 2018 14:55:27 GMT
Content-Length: 0

On a side note: there is no API endpoint for tags and the releases endpoint only shows releases (which is kind-a logical)

Is this working for anybody/nobody? Am I using it wrong?

[HoffmannP]

I can report that pretty obviouse there is no result as all requests are translated into the following sql

SELECT `id`, `index`, `repo_id`, `state`, `sha`, `target_url`, `description`, `context`, `creator_id`, `created_unix`, `updated_unix` FROM `commit_status` WHERE (repo_id = ?) AND (sha = ?) LIMIT 10

but the table commit_status is empty. Everything besides the complete sha-key would hence not work anyway.

[HoffmannP]

I seem to have solved the problem: commit status is not the commit itself but some state that you could set and afterwords read. So the problem seems to be that commit status can't be set to external commits? At least it is in need of documentation. But the API might even work as expected but was never filled with any data. So: commit/status != commit

Another documentation problem I couldn't solve even after reading routers/api/v1/api.go and routers/api/v1/repo/file.go is GetArchive. The last parameter "archive" is neither understandably documented nor does the function called by this route use it anywhere. As a result I only get a 404.

> curl -D - -s "https://$server/api/v1/repos/$user/$repo/archive/HEAD -H "Authorization: token $token"
HTTP/1.1 404 Not Found
…

So after all I'm still missing a way to access the repository and it's commit logs itself

[techknowlogick]

There was just a code change that went through for creating releases.

[HoffmannP]

Thank you for the information, I will check with the next release.

[eapetitfils]

I still have the issue for the release creation with the version 1.5.2. I can fetch the different rleases, create an issue but I cannot create a release.

Here is the python code I used to test it, which returns a 404 error.

release_body = {
  "body": "hello",
  "draft": True,
  "name": "0.2.2",
  "prerelease": True,
  "tag_name": "0.2.2",
  "target_commitish": "string"
}
a = requests.post(server + '/api/v1/repos/' + user + '/' + repo + '/releases?token=' + token,
                  data=release_body, proxies=proxies, verify=cert, timeout=10, )
try:
    print(a.json())
except:
    print(a.status_code, a.reason)

Update:
Note that I can use create a release on try.gitea.io using swagger and curl, but the python code above returns {'message': 'GetBranchCommit: object does not exist [id: refs/heads/, rel_path: ]', 'url': 'https://godoc.org/github.com/go-gitea/go-sdk/gitea'}.

[HoffmannP]

Probably a quite stupid question, but: What did you use as "target_commitish"? Did you literally use "string" or a real commitId/branch:HEAD/etc...?

[lunny]

@HoffmannP you can use branch/tag/full commitid/short commitid

[HoffmannP]

@lunny that's how I understand it as well, I was just wondering what @eapetitfils was using

[lunny]

@HoffmannP Before #5076 merged, you can only use branch name, but #5076 fixed that.

[eapetitfils]

@HoffmannP Not that stupid as I was just using "string", which works on try.gitea.io with CURL. I did some tests with a proper value (master:HEAD and the short commitid), but with the same results.

I tried the following that works with CURL:
curl -X POST "https://try.gitea.io/api/v1/repos/epetitfils/test/releases?access_token=****" -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"body\": \"string\", \"draft\": true, \"name\": \"0.1.4\", \"prerelease\": true, \"tag_name\": \"0.1.4\", \"target_commitish\": \"master:HEAD\"}"

but does not work with python:

server = 'https://try.gitea.io'
user = 'epetitfils'
repo = 'test'
token = '*****'
release_body = {
  "body": "hello",
  "draft": True,
  "name": "0.1.5",
  "prerelease": True,
  "tag_name": "0.1.5",
  "target_commitish": "master:HEAD"
}
a = requests.post(server + '/api/v1/repos/' + user + '/' + repo + '/releases?access_token=' + token,
                  data=release_body, proxies=proxies, verify=cert, timeout=10, )
try:
    print(a.json())
except:
    print(a.status_code, a.reason)

returns: {'message': "GetCommit: exit status 128 - fatal: ambiguous argument '': unknown revision or path not in the working tree.\nUse '--' to separate paths from revisions, like this:\n'git <command> [<revision>...] -- [<file>...]'\n", 'url': 'https://godoc.org/github.com/go-gitea/go-sdk/gitea'}

And both methods return an error 404 on my work server. I will do more test on my work server (installed on Ubuntu directly with the binary, no docker) as there should not be a difference between try.gitea.io and it. Then I will try to understand why the python code does not work as CURL, even though the adjusted code can be used to create issues.

[eapetitfils]

I found the problem in the python code. I was not preparing properly the payload and not setting the headers accordingly. Here is what it should be

server = 'https://try.gitea.io'
user = 'epetitfils'
repo = 'test'
token = '*****'
release_body = {
  "body": "hello",
  "draft": True,
  "name": "0.1.5",
  "prerelease": True,
  "tag_name": "0.1.5",
  "target_commitish": "master:HEAD"
}
a = requests.post(server + '/api/v1/repos/' + user + '/' + repo + '/releases?access_token=' + token,
                  data=json.dumps(release_body), timeout=10, headers={'content-type': 'application/json'})
try:
    print(a.json())
except:
    print(a.status_code, a.reason)

Also, the 404 error on my own server somehow fixed itself with an upgrade to 1.6.2.