Drone auth not working with internal users #3301

Closed
opened 2025-11-02 05:07:10 -06:00 by GiteaMirror · 27 comments
Owner

Originally created by @salcedo on GitHub (May 9, 2019).

  • 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

Originally created by @salcedo on GitHub (May 9, 2019). <!-- NOTE: If your issue is a security concern, please send an email to security@gitea.io instead of opening a public issue --> <!-- 1. Please speak English, this is the language all maintainers can speak and write. 2. Please ask questions or configuration/deploy problems on our Discord server (https://discord.gg/gitea) or forum (https://discourse.gitea.io). 3. Please take a moment to check that your issue doesn't already exist. 4. Please give all relevant information below for bug reports, because incomplete details will be handled as an invalid report. --> - 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 <!-- **If this issue involves the Web Interface, please include a screenshot** -->
GiteaMirror added the type/bug label 2025-11-02 05:07:11 -06:00
Author
Owner

@kimpenhaus commented on GitHub (May 9, 2019):

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.

@kimpenhaus commented on GitHub (May 9, 2019): 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.
Author
Owner

@pylanglois commented on GitHub (May 9, 2019):

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

@pylanglois commented on GitHub (May 9, 2019): 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
Author
Owner

@Sy0xFF commented on GitHub (May 10, 2019):

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" "-"
@Sy0xFF commented on GitHub (May 10, 2019): Let me add some additional information here. Looks like I have the same issue with the following setup: Docker compose: ```yaml 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.<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.<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" "-" ```
Author
Owner

@jonny5532 commented on GitHub (May 11, 2019):

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':
46373e7657 (diff-e8b760d6f593a855db95ca635708d685L9470)

@jonny5532 commented on GitHub (May 11, 2019): 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': https://github.com/go-gitea/gitea/commit/46373e765702a203bfcb576c9d3639314ef4965f#diff-e8b760d6f593a855db95ca635708d685L9470
Author
Owner

@jonny5532 commented on GitHub (May 11, 2019):

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

@jonny5532 commented on GitHub (May 11, 2019): 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).
Author
Owner

@iddm commented on GitHub (May 11, 2019):

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.

@iddm commented on GitHub (May 11, 2019): > This problem was apparently fixed by [1dc4016](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). I still have the same problem right on that version.
Author
Owner

@lafriks commented on GitHub (May 11, 2019):

Fixed in #6903

@lafriks commented on GitHub (May 11, 2019): Fixed in #6903
Author
Owner

@jonny5532 commented on GitHub (May 11, 2019):

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.

@jonny5532 commented on GitHub (May 11, 2019): 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.
Author
Owner

@techknowlogick commented on GitHub (May 11, 2019):

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.

@techknowlogick commented on GitHub (May 11, 2019): 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.
Author
Owner

@jonny5532 commented on GitHub (May 11, 2019):

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?

@jonny5532 commented on GitHub (May 11, 2019): 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?
Author
Owner

@iddm commented on GitHub (May 12, 2019):

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.

@iddm commented on GitHub (May 12, 2019): 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.
Author
Owner

@xoxys commented on GitHub (May 12, 2019):

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

@xoxys commented on GitHub (May 12, 2019): @techknowlogick Just to clarify, is Gitea 1.8.1 Oauth fully working with Drone?
Author
Owner

@lafriks commented on GitHub (May 12, 2019):

@xoxys yes it is

@lafriks commented on GitHub (May 12, 2019): @xoxys yes it is
Author
Owner

@xoxys commented on GitHub (May 12, 2019):

@lafriks Thanks :)

@xoxys commented on GitHub (May 12, 2019): @lafriks Thanks :)
Author
Owner

@vtolstov commented on GitHub (May 13, 2019):

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

@vtolstov commented on GitHub (May 13, 2019): i can't run drone:latest with gitea:latest, i'm setup oauth2, but drone says: Login Failed. unauthorized_client: client is not authorized
Author
Owner

@kranzo commented on GitHub (May 14, 2019):

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

@kranzo commented on GitHub (May 14, 2019): Which actual versions do you run? Did you manually pull updated images before testing? And what are the steps you used to setup oauth?
Author
Owner

@kimpenhaus commented on GitHub (May 14, 2019):

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
Bildschirmfoto 2019-05-14 um 09 16 04
  1. The Redirect URI must be identical to that used from drone. Mine is https://:/login

Bildschirmfoto 2019-05-14 um 09 16 15

  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.

Bildschirmfoto 2019-05-14 um 09 17 04

That's it...

@kimpenhaus commented on GitHub (May 14, 2019): Running both gitea and drone on latest docker images (managed by [containrrr/watchtower](https://github.com/containrrr/watchtower) - which is the newly maintained v2tec/watchtower). 1. You need to register drone application in gitea. `settings -> applications -> Manage OAuth2 applications` <img width="1143" alt="Bildschirmfoto 2019-05-14 um 09 16 04" src="https://user-images.githubusercontent.com/575109/57678530-b1309a80-7629-11e9-8bfc-7be5632a9188.png"> 2. The `Redirect URI` must be identical to that used from drone. Mine is https://<url-to-drone>:<port-of-drone>/login ![Bildschirmfoto 2019-05-14 um 09 16 15](https://user-images.githubusercontent.com/575109/57678591-d91ffe00-7629-11e9-983b-8b29ddfce1bb.png) 3. 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. 4. What I need to adjust was `DRONE_SERVER_HOST` which seems to have the port also - otherwise the redirect uri is not constructed proper. ![Bildschirmfoto 2019-05-14 um 09 17 04](https://user-images.githubusercontent.com/575109/57678741-2603d480-762a-11e9-84ab-ba274fe03319.png) That's it...
Author
Owner

@vtolstov commented on GitHub (May 14, 2019):

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 
@vtolstov commented on GitHub (May 14, 2019): 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 ```
Author
Owner

@xoxys commented on GitHub (May 18, 2019):

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

@xoxys commented on GitHub (May 18, 2019): @kimpenhaus works like a charm, thanks for the step by step guide!
Author
Owner

@lunny commented on GitHub (May 19, 2019):

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

@lunny commented on GitHub (May 19, 2019): @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?
Author
Owner

@kimpenhaus commented on GitHub (May 19, 2019):

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

@kimpenhaus commented on GitHub (May 19, 2019): @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.
Author
Owner

@lunny commented on GitHub (May 19, 2019):

@kimpenhaus that's better.

@lunny commented on GitHub (May 19, 2019): @kimpenhaus that's better.
Author
Owner

@xoxys commented on GitHub (May 19, 2019):

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

@xoxys commented on GitHub (May 19, 2019): As i know drone docs sources are not public available for now
Author
Owner

@kimpenhaus commented on GitHub (May 19, 2019):

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

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

@kimpenhaus commented on GitHub (May 19, 2019): > As i know drone docs sources are not public available for now It looks like ... those on github are either archived or deprecated
Author
Owner

@xoxys commented on GitHub (May 19, 2019):

Yeah....

@xoxys commented on GitHub (May 19, 2019): Yeah....
Author
Owner

@ro-kue commented on GitHub (Nov 3, 2019):

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.

@ro-kue commented on GitHub (Nov 3, 2019): 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 <my ip>: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.
Author
Owner

@niaiwomattt commented on GitHub (Oct 19, 2020):

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

@niaiwomattt commented on GitHub (Oct 19, 2020): > 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
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#3301