Gitea: Drone auth not working with internal users

[salcedo]

• Gitea version (or commit ref): 1.8.1
• Git version: N/A
• Operating system: Linux
• Database (use [x]):
  
  
  
  • [x] PostgreSQL
  
  
  • [ ] MySQL
  
  
  • [ ] MSSQL
  
  
  • [ ] SQLite
  
  
• Can you reproduce the bug at https://try.gitea.io:
  
  
  
  • [ ] Yes (provide example URL)
  
  
  • [ ] No
  
  
  • [x] Not relevant
  
  
• Log gist:

Description

Drone no longer works with Gitea as of 1.8.1. Logging into drone is successful in so much as I see it creates an access token in Gitea even after I delete it. After drone logs in and creates the token, it then hits /api/v1/user. Gitea responds with 401 Unauthorized.

I switched back to 1.8.0 as a workaround for now. Sorry I do not have more details. The logs were not very detailed. I suspect some of the auth bug fixes in 1.8.1 could have caused this. Can anyone else confirm drone no longer working with Gitea?

Screenshots

[kimpenhaus]

Can confirm having the same problem with gitea version 1.9.0+dev-223-g6db3dc7c0 and and latest drone. Was working fine until gitea update.

[pylanglois]

Same case for me. I tried to downgrade gitea to image 6b4465a87455 but it failed. I'm using gitea/gitea:latest 1.9.0+dev-223-g6db3dc7c0 with sqlite

[Sy0xFF]

Let me add some additional information here. Looks like I have the same issue with the following setup:

Docker compose:

version: "3"
services:
  nginx:
    image: nginx:latest
    ports:
      - 80:80
      - 443:443
    volumes:
      - ./data/nginx/config:/etc/nginx/conf.d

  gitea:
    image: gitea/gitea:latest
    restart: always
    volumes:
      - ./data/gitea:/data/gitea
    ports:
      - 3000:3000
      - 22:22

  drone:
    image: drone/drone:latest
    environment:
      - DRONE_GITEA_SERVER=https://git.<server>
      - DRONE_RUNNER_CAPACITY=2
      - DRONE_SERVER_HOST=drone.<server>
      - DRONE_SERVER_PROTO=https
      - DRONE_GIT_ALWAYS_AUTH=false
      - DRONE_RPC_SECRET=<secret>
    ports:
      - 81:80
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./data/drone:/data

nginx configuration:

```(conf)
server {
listen 443 ssl;
server_name git.;
ssl_certificate ####
ssl_certificate_key ####
location / {
proxy_pass http://gitea:3000;
proxy_set_header Host $host;
}
}
server {
listen 443 ssl;
server_name drone.;
ssl_certificate ####
ssl_certificate_key ####
location / {
proxy_pass http://drone:81;
proxy_set_header Host $host;
}
}

After loggin in on drone.<server> i get the message "Login Failed. Unauthorized".

docker compose log:

```terminal
gitea_1  | [Macaron] 2019-05-10 19:48:13: Started GET /api/v1/users/<user>/tokens for 172.26.0.2
gitea_1  | [Macaron] 2019-05-10 19:48:13: Completed GET /api/v1/users/<user>/tokens 200 OK in 39.309966ms
nginx_1  | 11.111.111.11 - <user> [10/May/2019:19:48:13 +0000] "GET /api/v1/users/<user>/tokens HTTP/1.1" 200 35 "-" "Go-http-client/1.1" "-"
gitea_1  | [Macaron] 2019-05-10 19:48:13: Started GET /api/v1/user for 172.26.0.2
gitea_1  | [Macaron] 2019-05-10 19:48:13: Completed GET /api/v1/user 401 Unauthorized in 318.568µs
nginx_1  | 11.111.111.11 - - [10/May/2019:19:48:13 +0000] "GET /api/v1/user HTTP/1.1" 401 0 "-" "Go-http-client/1.1" "-"
nginx_1  | 11.111.111.11 - - [10/May/2019:19:48:13 +0000] "POST /login HTTP/1.1" 303 0 "https://drone.<server>/login/form" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36" "-"
nginx_1  | 11.111.111.11 - - [10/May/2019:19:48:13 +0000] "GET /login/error?message=Unauthorized HTTP/1.1" 200 786 "https://drone.<server>/login/form" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36" "-"
nginx_1  | 11.111.111.11 - - [10/May/2019:19:48:13 +0000] "GET /api/user HTTP/1.1" 401 27 "https://drone.<server>/login/error?message=Unauthorized" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36" "-"
nginx_1  | 11.111.111.11 - - [10/May/2019:19:48:15 +0000] "GET /serviceworker.js HTTP/1.1" 200 786 "https://drone.<server>/serviceworker.js" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36" "-"

[jonny5532]

I think I'm encountering the same issue - looking at the HTTP requests from Drone to Gitea I can see the token creation working fine (with Authorization: basic):

POST /api/v1/users/jonny/tokens HTTP/1.1
Authorization: Basic am9*************
Content-Type: application/json

{"name":"drone"}

HTTP/1.1 201 Created
Content-Type: application/json; charset=UTF-8
Set-Cookie: ...

{"id":8,"name":"drone","token":"1448ee**********************************","hashed_token":"","token_last_eight":""}



md5-a7278cffd7106da1cb6e218356afe616



GET /api/v1/user HTTP/1.1
Authorization: token



md5-fd6c5ebe9f137b61ecac8d544581a9e5



HTTP/1.1 403 Forbidden
Content-Type: application/json; charset=UTF-8
Set-Cookie: ...

{"message":"Only signed in user is allowed to call APIs."}

The token is clearly being returned back to Drone in the token creation step, but Drone is not then using it correctly for the subsequent call. Perhaps the token-create response format has changed and is confusing Drone?

Update: it looks like the token-create response has indeed changed, with 'sha1' changing to 'token':
https://github.com/go-gitea/gitea/commit/46373e765702a203bfcb576c9d3639314ef4965f#diff-e8b760d6f593a855db95ca635708d685L9470

[jonny5532]

This problem was apparently fixed by https://github.com/go-gitea/gitea/commit/1dc401635b8acb20f4222216ad0828ef39617989 (I can confirm that it is fixed in 1.9.0+dev-231-g34eee25bd - Drone is authenticating without the error).

[vityafx]

This problem was apparently fixed by 1dc4016 (I can confirm that it is fixed in 1.9.0+dev-231-g34eee25bd - Drone is authenticating without the error).

I still have the same problem right on that version.

[lafriks]

Fixed in #6903

[jonny5532]

It worked earlier for me but I have just had a recurrence. I had to go into Gitea -> Settings -> Applications and delete the 'drone' token, after which Drone could then reconnect (recreating the token).
I'm not yet sure what the cause is.

Update: And it just happened again after logging out of Drone - deleting the token then fixed it, so something is not right somewhere. The token-create API call does return a different sha1 each time, suggesting that it is recreating the token as it should be.

[techknowlogick]

That’s likely because the token is now hashed for security reason. Drone tried to fetch it again which doesn’t work because it cant, as we are using a one way hash function. However OAuth2 is the recommended way of using Drone.

[jonny5532]

Indeed, I just tried Gitea 1.8.0 again and the call to /tokens does return the token itself which Drone expects, not so with the newer versions.

So presumably either the Drone documentation needs updating to remove the non-OAuth2 method as it is now broken, or Drone needs changing to regenerate the token each time (via Basic auth) as it can no longer retrieve the previous one?

[vityafx]

On gitea 1.9.0+dev-233-g13583a650 and still, I have the same problem. So I simply did what @jonny5532 said, and everything worked: I removed the token from gitea, and then the drone itself made another one in gitea, and everything worked.

[xoxys]

@techknowlogick Just to clarify, is Gitea 1.8.1 Oauth fully working with Drone?

[lafriks]

@xoxys yes it is

[xoxys]

@lafriks Thanks :)

[vtolstov]

i can't run drone:latest with gitea:latest, i'm setup oauth2, but drone says: Login Failed. unauthorized_client: client is not authorized

[kranzo]

Which actual versions do you run? Did you manually pull updated images before testing? And what are the steps you used to setup oauth?

[kimpenhaus]

Running both gitea and drone on latest docker images (managed by containrrr/watchtower - which is the newly maintained v2tec/watchtower).

1. You need to register drone application in gitea. settings -> applications -> Manage OAuth2 applications

1. The Redirect URI must be identical to that used from drone. Mine is https://:/login

1. You need to set the env parameters in the docker container DRONE_GITEA_CLIENT_ID and DRONE_GITEA_CLIENT_SECRET - both generated in step 1./2. after saving.

2. What I need to adjust was DRONE_SERVER_HOST which seems to have the port also - otherwise the redirect uri is not constructed proper.

That's it...

[vtolstov]

i'm try and it not works. i'm pull latest from drone and gitea now. recheck oauth2 settings but when i'm try auth in drone i get error like before. why gitea returns bad request?

May 14 19:18:51 central01.z1.unistack.org dockerd-current[1517]: [Macaron] 2019-05-14 16:18:51: Started POST /login/oauth/access_token f
or 172.18.0.100
May 14 19:18:51 central01.z1.unistack.org docker[14542]: [Macaron] 2019-05-14 16:18:51: Started POST /login/oauth/access_token for 172.1
8.0.100
May 14 19:18:51 central01.z1.unistack.org dockerd-current[1517]: 2019/05/14 16:18:51 .../xorm/session_get.go:95:nocacheGet() [I] [SQL] S
ELECT `id`, `uid`, `name`, `client_id`, `client_secret`, `redirect_uris`, `created_unix`, `updated_unix` FROM `oauth2_application` WHERE
 (client_id = ?) LIMIT 1 []interface {}{"047a2bfd-69c1-49ed-b8b1-594d1ce538aa"}
May 14 19:18:51 central01.z1.unistack.org docker[14542]: 2019/05/14 16:18:51 .../xorm/session_get.go:95:nocacheGet() [I] [SQL] SELECT `i
d`, `uid`, `name`, `client_id`, `client_secret`, `redirect_uris`, `created_unix`, `updated_unix` FROM `oauth2_application` WHERE (client
_id = ?) LIMIT 1 []interface {}{"047a2bfd-69c1-49ed-b8b1-594d1ce538aa"}
May 14 19:18:52 central01.z1.unistack.org dockerd-current[1517]: [Macaron] 2019-05-14 16:18:52: Completed POST /login/oauth/access_token
 400 Bad Request in 114.665538ms
May 14 19:18:52 central01.z1.unistack.org docker[14542]: [Macaron] 2019-05-14 16:18:52: Completed POST /login/oauth/access_token 400 Bad
 Request in 114.665538ms
May 14 19:18:52 central01.z1.unistack.org dockerd-current[1517]: ERRO[0013] oauth: cannot exchange code: OlyzwZ8_6aB0r3wgu4q1uh6uKB9iluy
oeQodwWREw5Q=: unauthorized_client: client is not authorized 
May 14 19:18:52 central01.z1.unistack.org dockerd-current[1517]: DEBU[0013] cannot authenticate user: unauthorized_client: client is not
 authorized 

[xoxys]

@kimpenhaus works like a charm, thanks for the step by step guide!

[lunny]

@kimpenhaus would you like to post a blog on gitea or send it to docs so that more people could get benefits from your comment?

[kimpenhaus]

@lunny don't you think it would be more beneficial to put it into the drone docs as that's the system that wants to authenticate? I could check if they would accept a pull request on their docs for an addition in oauth2 with gitea.

[lunny]

@kimpenhaus that's better.

[xoxys]

As i know drone docs sources are not public available for now

[kimpenhaus]

As i know drone docs sources are not public available for now

It looks like ... those on github are either archived or deprecated

[xoxys]

Yeah....

[ro-kue]

I still have this problem but found a way to resolve this. However, this is the first and only Google result you get when you google this issue in the most straight forward way so I hope it is okay if I post my solution here.

My setup: Drone and Gitea both in docker in their own networks with a shared network used for a reverse proxy via Caddy. Caddy maps subdomains to docker host names so ci.example.com leads to drone and gitea.example.com leads to gitea. I use the domain for the drone gitea configs.

I could login via OAuth 2 but then it just said "bla bla :443 no route to host".

I fixed this by allowing https in my firewall. Technically this is not necessary because docker is opening all ports you publish but in this case, I had to do it manually.

Then I had some other issues with DNS stuff. Since Drone was literally never functional I took the easy way out and stopped all drone containers, deleted everything in the database volume and restarted all drone containers and then it worked flawlessly.

[niaiwomattt]

I still have this problem but found a way to resolve this. However, this is the first and only Google result you get when you google this issue in the most straight forward way so I hope it is okay if I post my solution here.

My setup: Drone and Gitea both in docker in their own networks with a shared network used for a reverse proxy via Caddy. Caddy maps subdomains to docker host names so ci.example.com leads to drone and gitea.example.com leads to gitea. I use the domain for the drone gitea configs.

I could login via OAuth 2 but then it just said "bla bla :443 no route to host".

I fixed this by allowing https in my firewall. Technically this is not necessary because docker is opening all ports you publish but in this case, I had to do it manually.

Then I had some other issues with DNS stuff. Since Drone was literally never functional I took the easy way out and stopped all drone containers, deleted everything in the database volume and restarted all drone containers and then it worked flawlessly.

什么意思？没看懂，dns 如何支持 https ？我的 docker-compose.yaml 已经配置了 https 端口，但是我外部使用 nginx 代理的，没必要 https