New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
HoffmannP opened this Issue Apr 23, 2018 · 22 comments

Comments

8 participants
@HoffmannP
Contributor

HoffmannP commented Apr 23, 2018

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

This comment has been minimized.

Contributor

HoffmannP commented Apr 23, 2018

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

This comment has been minimized.

Contributor

HoffmannP commented Jun 6, 2018

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

This comment has been minimized.

markuman commented Jun 12, 2018

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

@HoffmannP

This comment has been minimized.

Contributor

HoffmannP commented Jun 13, 2018

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

This comment has been minimized.

markuman commented Jun 13, 2018

I like to reference to #4234 also

@HoffmannP HoffmannP changed the title from At least two API calls don't work to At least <strikethrough>two<strikethrough> three API calls don't work Jun 13, 2018

@HoffmannP HoffmannP changed the title from At least <strikethrough>two<strikethrough> three API calls don't work to At least -t-w-o- three API calls don't work Jun 13, 2018

@HoffmannP HoffmannP changed the title from At least -t-w-o- three API calls don't work to At least t̶w̶o̶ three API calls don't work Jun 13, 2018

@markuman

This comment has been minimized.

markuman commented Jun 15, 2018

@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

This comment has been minimized.

Contributor

HoffmannP commented Jun 15, 2018

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

This comment has been minimized.

Member

bkcsoft commented Jun 15, 2018

/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

This comment has been minimized.

markuman commented Jun 16, 2018

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

$ curl --request GET --url https://m:mypassword@git.osuv.de/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:mypassword@git.osuv.de/api/v1/users/fasgdjfhgdsf/tokens
[{"name":"test","sha1":"..."},{"name":"dev","sha1":"..."}]
$

@markuman markuman referenced this issue Jun 16, 2018

Closed

missing route DELETE /users/{username}/tokens #4234

2 of 7 tasks complete
@kainz

This comment has been minimized.

kainz commented Jun 24, 2018

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

This comment has been minimized.

Member

techknowlogick commented Jun 27, 2018

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

This comment has been minimized.

Contributor

HoffmannP commented Aug 13, 2018

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

This comment has been minimized.

Contributor

HoffmannP commented Aug 14, 2018

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

This comment has been minimized.

Contributor

HoffmannP commented Aug 15, 2018

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

This comment has been minimized.

Member

techknowlogick commented Sep 11, 2018

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

@HoffmannP

This comment has been minimized.

Contributor

HoffmannP commented Sep 11, 2018

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

@eapetitfils

This comment has been minimized.

eapetitfils commented Oct 12, 2018

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

This comment has been minimized.

Contributor

HoffmannP commented Oct 15, 2018

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

This comment has been minimized.

Member

lunny commented Oct 15, 2018

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

@HoffmannP

This comment has been minimized.

Contributor

HoffmannP commented Oct 15, 2018

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

@lunny

This comment has been minimized.

Member

lunny commented Oct 15, 2018

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

@eapetitfils

This comment has been minimized.

eapetitfils commented Oct 15, 2018

@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.

@HoffmannP HoffmannP closed this Nov 23, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment