Gitea: API Authorization: header not working

Created on 13 Jun 2018  路  2Comments  路  Source: go-gitea/gitea

The Authorization: header doesn't seem to be working as of 2e05ffd6b6f264483ced3ad2bec62f8c0d6c9bdd. I haven't yet figured out what's causing this behavior, or if it's something I'm doing wrong. Seeing some possible similarities with some of the symptoms of #3842, particularly the 401 response described there when using Authorization:.

How to duplicate:

  • Using the /api/swagger web UI, hit the 'Authorize' button and put your token into the AuthorizationHeaderToken value field. Ensure you are logged out of all other authorization methods. Ensure you are logged out of the gitea web UI (no cookies stored in your browser).
  • Create a new issue using the swagger web UI; this will fail with a 401 Unauthorized error.
  • Now copy and execute the curl command given by the swagger web UI. It also fails. Adding a -i flag to curl shows that it is returning a 401 Unauthorized:
curl -X POST "http://localhost:4000/api/v1/repos/test1/test1/issues" -H "accept: application/json" -H "Authorization: 65eaa9c8ef52460d22a93307fe0aee76289dc675" -H "Content-Type: application/json" -d "{ \"body\": \"testing\", \"title\": \"test 17\"}" -i
HTTP/1.1 401 Unauthorized
Set-Cookie: lang=en-US; Path=/; Max-Age=2147483647
Set-Cookie: i_like_gitea=7e17b9f254cd0cc4; Path=/; HttpOnly
Set-Cookie: _csrf=vW3ET5wQ62_IHnj5j08A9KUfXQM6MTUyODkwODc5OTkyOTI5OTUxNw%3D%3D; Path=/; Expires=Thu, 14 Jun 2018 16:53:19 GMT
X-Frame-Options: SAMEORIGIN
Date: Wed, 13 Jun 2018 16:53:19 GMT
Content-Length: 0
  • Go back and hit the Authorize button again, log out of AuthorizationHeaderToken, and instead paste your token in the Token value field.
  • Try creating a new issue using the swagger web UI again; this will succeed.

Most helpful comment

Okay, for anyone landing here from google -- the way to get the Authorization: header to work from gitea API clients is to use your normal API key token, the same one you would use in the token= string in a GET request, but with the word token prepended. Like this:

Authorization: token 65eaa9c8ef52460d22a93307fe0aee76289dc675

In a curl command, for instance, this would look like:

curl -X POST "http://localhost:4000/api/v1/repos/test1/test1/issues" -H "accept: application/json" -H "Authorization: token 65eaa9c8ef52460d22a93307fe0aee76289dc675" -H "Content-Type: application/json" -d "{ \"body\": \"testing\", \"title\": \"test 20\"}" -i

The code that parses this is at https://github.com/go-gitea/gitea/blob/6efdcaed86565c91a3dc77631372a9cc45a58e89/modules/auth/auth.go#L47

Some related points:

  • Gitea doesn't support the X-API-Key header described in https://swagger.io/docs/specification/authentication/api-keys/ -- this might mean we're non-compliant with the openapi standard.
  • I think we use Authorization: token ... just because github does.
  • I do know this issue cost me a day of confusion. After I knew what to look for, finding #3673 as a dup of #4243 was trivial. As #3673 says, we need some sort of client API docs or guide.

All 2 comments

Closing for now because I'm probably an idiot -- the Authorization: header probably isn't supposed to work with the same token type that works in the query string, and I should probably know better.

Okay, for anyone landing here from google -- the way to get the Authorization: header to work from gitea API clients is to use your normal API key token, the same one you would use in the token= string in a GET request, but with the word token prepended. Like this:

Authorization: token 65eaa9c8ef52460d22a93307fe0aee76289dc675

In a curl command, for instance, this would look like:

curl -X POST "http://localhost:4000/api/v1/repos/test1/test1/issues" -H "accept: application/json" -H "Authorization: token 65eaa9c8ef52460d22a93307fe0aee76289dc675" -H "Content-Type: application/json" -d "{ \"body\": \"testing\", \"title\": \"test 20\"}" -i

The code that parses this is at https://github.com/go-gitea/gitea/blob/6efdcaed86565c91a3dc77631372a9cc45a58e89/modules/auth/auth.go#L47

Some related points:

  • Gitea doesn't support the X-API-Key header described in https://swagger.io/docs/specification/authentication/api-keys/ -- this might mean we're non-compliant with the openapi standard.
  • I think we use Authorization: token ... just because github does.
  • I do know this issue cost me a day of confusion. After I knew what to look for, finding #3673 as a dup of #4243 was trivial. As #3673 says, we need some sort of client API docs or guide.
Was this page helpful?
0 / 5 - 0 ratings