Drone auth not working with internal users #6883

salcedo · 2019-05-09T01:36:22Z

Gitea version (or commit ref): 1.8.1
Git version: N/A
Operating system: Linux
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

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

The text was updated successfully, but these errors were encountered:

kimpenhaus · 2019-05-09T07:00:51Z

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 · 2019-05-09T13:32:25Z

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 · 2019-05-10T19:57:00Z

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:

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

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

docker compose log:

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 · 2019-05-11T10:10:03Z

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":""}

But then the subsequent user profile request fails, because the 'Authorization: token' header is missing the actual token:

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

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':
46373e7#diff-e8b760d6f593a855db95ca635708d685L9470

jonny5532 · 2019-05-11T16:14:52Z

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

iddm · 2019-05-11T19:55:52Z

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 · 2019-05-11T20:34:03Z

Fixed in #6903

jonny5532 · 2019-05-11T20:37:00Z

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 · 2019-05-11T20:48:24Z

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 · 2019-05-11T20:50:37Z

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?

iddm · 2019-05-12T06:42:36Z

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 · 2019-05-12T12:59:05Z

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

lafriks · 2019-05-12T13:02:45Z

@xoxys yes it is

xoxys · 2019-05-12T13:03:59Z

@lafriks Thanks :)

vtolstov · 2019-05-13T21:49:53Z

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 · 2019-05-14T06:02:58Z

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 · 2019-05-14T07:27:18Z

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

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

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

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.
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 · 2019-05-14T16:20:42Z

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 · 2019-05-18T23:21:32Z

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

lunny · 2019-05-19T02:18:58Z

@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 · 2019-05-19T06:38:03Z

@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 · 2019-05-19T06:39:10Z

@kimpenhaus that's better.

xoxys · 2019-05-19T10:00:32Z

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

kimpenhaus · 2019-05-19T10:04:28Z

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

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

xoxys · 2019-05-19T10:05:49Z

Yeah....

ro-kue · 2019-11-03T10:52:54Z

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 · 2020-10-19T08:04:17Z

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

lunny added the type/bug label May 10, 2019

lafriks closed this as completed May 11, 2019

lafriks added this to the 1.9.0 milestone May 11, 2019

alexanderadam mentioned this issue Nov 11, 2019

drone not able to auth via oauth2 #6939

Closed

go-gitea locked and limited conversation to collaborators Nov 24, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Drone auth not working with internal users #6883

Drone auth not working with internal users #6883

salcedo commented May 9, 2019

kimpenhaus commented May 9, 2019

pylanglois commented May 9, 2019 •

edited

Loading

Sy0xFF commented May 10, 2019

jonny5532 commented May 11, 2019 •

edited

Loading

jonny5532 commented May 11, 2019

iddm commented May 11, 2019

lafriks commented May 11, 2019

jonny5532 commented May 11, 2019 •

edited

Loading

techknowlogick commented May 11, 2019

jonny5532 commented May 11, 2019 •

edited

Loading

iddm commented May 12, 2019 •

edited

Loading

xoxys commented May 12, 2019

lafriks commented May 12, 2019

xoxys commented May 12, 2019

vtolstov commented May 13, 2019

kranzo commented May 14, 2019

kimpenhaus commented May 14, 2019 •

edited

Loading

vtolstov commented May 14, 2019

xoxys commented May 18, 2019

lunny commented May 19, 2019

kimpenhaus commented May 19, 2019

lunny commented May 19, 2019

xoxys commented May 19, 2019

kimpenhaus commented May 19, 2019

xoxys commented May 19, 2019

ro-kue commented Nov 3, 2019

niaiwomattt commented Oct 19, 2020

Drone auth not working with internal users #6883

Drone auth not working with internal users #6883

Comments

salcedo commented May 9, 2019

Description

Screenshots

kimpenhaus commented May 9, 2019

pylanglois commented May 9, 2019 • edited Loading

Sy0xFF commented May 10, 2019

jonny5532 commented May 11, 2019 • edited Loading

jonny5532 commented May 11, 2019

iddm commented May 11, 2019

lafriks commented May 11, 2019

jonny5532 commented May 11, 2019 • edited Loading

techknowlogick commented May 11, 2019

jonny5532 commented May 11, 2019 • edited Loading

iddm commented May 12, 2019 • edited Loading

xoxys commented May 12, 2019

lafriks commented May 12, 2019

xoxys commented May 12, 2019

vtolstov commented May 13, 2019

kranzo commented May 14, 2019

kimpenhaus commented May 14, 2019 • edited Loading

vtolstov commented May 14, 2019

xoxys commented May 18, 2019

lunny commented May 19, 2019

kimpenhaus commented May 19, 2019

lunny commented May 19, 2019

xoxys commented May 19, 2019

kimpenhaus commented May 19, 2019

xoxys commented May 19, 2019

ro-kue commented Nov 3, 2019

niaiwomattt commented Oct 19, 2020

pylanglois commented May 9, 2019 •

edited

Loading

jonny5532 commented May 11, 2019 •

edited

Loading

jonny5532 commented May 11, 2019 •

edited

Loading

jonny5532 commented May 11, 2019 •

edited

Loading

iddm commented May 12, 2019 •

edited

Loading

kimpenhaus commented May 14, 2019 •

edited

Loading