drone not able to auth via oauth2 #3327

Closed
opened 2025-11-02 05:08:32 -06:00 by GiteaMirror · 13 comments
Owner

Originally created by @vtolstov on GitHub (May 13, 2019).

drone:latest can login to gitea:latest, i'm create app in gitea oauth2 screnn and set env varaibles for drone, but when i'm authorize drone i get error:
Login Failed. unauthorized_client: client is not authorized

May 14 01:24:09 central01.z1.unistack.org dockerd-current[1517]: [Macaron] 2019-05-13 22:24:09: Completed POST /login/oauth/access_token
 400 Bad Request in 114.064282ms
May 14 01:24:09 central01.z1.unistack.org docker[15577]: [Macaron] 2019-05-13 22:24:09: Completed POST /login/oauth/access_token 400 Bad
 Request in 114.064282ms
May 14 01:24:09 central01.z1.unistack.org dockerd-current[1517]: ERRO[0252] oauth: cannot exchange code: GkQ1EgbX-ZmG8PCfi0IYWiK2T9ICbIo
QSQi4uI-0c94=: unauthorized_client: client is not authorized 

Originally created by @vtolstov on GitHub (May 13, 2019). drone:latest can login to gitea:latest, i'm create app in gitea oauth2 screnn and set env varaibles for drone, but when i'm authorize drone i get error: Login Failed. unauthorized_client: client is not authorized ``` May 14 01:24:09 central01.z1.unistack.org dockerd-current[1517]: [Macaron] 2019-05-13 22:24:09: Completed POST /login/oauth/access_token 400 Bad Request in 114.064282ms May 14 01:24:09 central01.z1.unistack.org docker[15577]: [Macaron] 2019-05-13 22:24:09: Completed POST /login/oauth/access_token 400 Bad Request in 114.064282ms May 14 01:24:09 central01.z1.unistack.org dockerd-current[1517]: ERRO[0252] oauth: cannot exchange code: GkQ1EgbX-ZmG8PCfi0IYWiK2T9ICbIo QSQi4uI-0c94=: unauthorized_client: client is not authorized ```
GiteaMirror added the issue/needs-feedback label 2025-11-02 05:08:32 -06:00
Author
Owner

@DblK commented on GitHub (May 15, 2019):

I do not know for sure for latest of gitea version but version 1.8.1 can work again with drone.

@DblK commented on GitHub (May 15, 2019): I do not know for sure for `latest` of gitea version but version `1.8.1` can work again with drone.
Author
Owner

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

All works fine now

@vtolstov commented on GitHub (May 15, 2019): All works fine now
Author
Owner

@PhilsLab commented on GitHub (Sep 10, 2019):

I'm still experiencing this issue:

gitea_1        | [Macaron] 2019-09-10 10:47:17: Started POST /login/oauth/grant for XXX.XXX.XXX.XXX
gitea_1        | [Macaron] 2019-09-10 10:47:17: Completed POST /login/oauth/grant 302 Found in 36.181938ms
gitea_1        | [Macaron] 2019-09-10 10:47:17: Started GET /login/oauth/access_token for 172.20.0.1
gitea_1        | [Macaron] 2019-09-10 10:47:17: Completed GET /login/oauth/access_token 404 Not Found in 12.233255ms
drone_1        | {"level":"error","msg":"oauth: cannot exchange code: 2VQ4KdZ <...> 5RKYf98wJSMk=: : ","time":"2019-09-10T10:47:17Z"}

Redirects are working fine. Any ideas?

@PhilsLab commented on GitHub (Sep 10, 2019): I'm still experiencing this issue: ``` gitea_1 | [Macaron] 2019-09-10 10:47:17: Started POST /login/oauth/grant for XXX.XXX.XXX.XXX gitea_1 | [Macaron] 2019-09-10 10:47:17: Completed POST /login/oauth/grant 302 Found in 36.181938ms gitea_1 | [Macaron] 2019-09-10 10:47:17: Started GET /login/oauth/access_token for 172.20.0.1 gitea_1 | [Macaron] 2019-09-10 10:47:17: Completed GET /login/oauth/access_token 404 Not Found in 12.233255ms drone_1 | {"level":"error","msg":"oauth: cannot exchange code: 2VQ4KdZ <...> 5RKYf98wJSMk=: : ","time":"2019-09-10T10:47:17Z"} ``` Redirects are working fine. Any ideas?
Author
Owner

@sleepycodernotes commented on GitHub (Nov 11, 2019):

pump

@sleepycodernotes commented on GitHub (Nov 11, 2019): pump
Author
Owner

@alexanderadam commented on GitHub (Nov 11, 2019):

@sleepycodernotes IMHO this was an issue that should be fixed by now.
See Drone issue 2704 for more information.

See this comment for a description how to configure it properly:

Screenshot_20191111_140048

https://github.com/drone/drone/issues/2704#issuecomment-552084152 / https://github.com/go-gitea/gitea/issues/6883#issuecomment-492112398

@alexanderadam commented on GitHub (Nov 11, 2019): @sleepycodernotes IMHO this was an issue that should be fixed by now. See [Drone issue 2704](https://github.com/drone/drone/issues/2704) for more information. <details> <summary>See this comment for a description how to configure it properly:</summary> ![Screenshot_20191111_140048](https://user-images.githubusercontent.com/372620/68589263-be6cfb80-048b-11ea-8e87-a5c10f7bc20c.png) </details> https://github.com/drone/drone/issues/2704#issuecomment-552084152 / https://github.com/go-gitea/gitea/issues/6883#issuecomment-492112398
Author
Owner

@sleepycodernotes commented on GitHub (Nov 11, 2019):

image

@sleepycodernotes commented on GitHub (Nov 11, 2019): ![image](https://user-images.githubusercontent.com/12711726/68589978-0b55cf80-0496-11ea-99d5-e82ece6563a1.png)
Author
Owner

@sleepycodernotes commented on GitHub (Nov 11, 2019):

Using latest images : gitea/drone/treafik/portainer

@sleepycodernotes commented on GitHub (Nov 11, 2019): Using latest images : gitea/drone/treafik/portainer
Author
Owner

@alexanderadam commented on GitHub (Nov 11, 2019):

  1. Did you follow the explanation I linked to? https://github.com/drone/drone/issues/2704#issuecomment-552084152 / https://github.com/go-gitea/gitea/issues/6883#issuecomment-492112398
  2. If you have a firewall: did you ensure that both containers can connect to each other?
@alexanderadam commented on GitHub (Nov 11, 2019): 1. Did you follow the explanation I linked to? https://github.com/drone/drone/issues/2704#issuecomment-552084152 / https://github.com/go-gitea/gitea/issues/6883#issuecomment-492112398 2. If you have a firewall: did you ensure [that both containers can connect to each other](https://github.com/drone/drone/issues/2704#issuecomment-545309655)?
Author
Owner

@sleepycodernotes commented on GitHub (Nov 11, 2019):

  1. i did
  2. i'm using windows 10 wsl 2, dont know where to look
@sleepycodernotes commented on GitHub (Nov 11, 2019): 1. i did 2. i'm using windows 10 wsl 2, dont know where to look
Author
Owner

@alexanderadam commented on GitHub (Nov 11, 2019):

  1. I'm not a Windows user but for testing whether the firewall might be the reason, you know, you could simply search in the internet.
@alexanderadam commented on GitHub (Nov 11, 2019): 2. I'm not a Windows user but for testing whether the firewall might be the reason, you know, [you could simply search in the internet](https://lmddgtfy.net/?q=deactivate%20windows%20firewall).
Author
Owner

@sleepycodernotes commented on GitHub (Nov 11, 2019):

Screenshot from 2019-11-11 16-01-37

as i understand windows firewall give permission to docker, i run docker-compose in ubuntu and can access all images from windows. All images are in same network

@sleepycodernotes commented on GitHub (Nov 11, 2019): ![Screenshot from 2019-11-11 16-01-37](https://user-images.githubusercontent.com/12711726/68592811-98038c00-049c-11ea-9c25-fda0209c8080.png) as i understand windows firewall give permission to docker, i run docker-compose in ubuntu and can access all images from windows. All images are in same network
Author
Owner

@alexanderadam commented on GitHub (Nov 11, 2019):

In that case I can't help you.
But it still looks like a network error (because it says connection refused in your screenshot).
I'm not sure whether the screen you showed here will also open Docker for the firewall.

Because you need to open port 3000 (see your other screenshot) and your screenshot only shows something about opening the Docker socket over 2375. And I guess it should be obvious that those don't have much to do with each other.
Also your Ubuntu instance could have a firewall (iptables / ufw).

So to summarize: no things you mentioned seem to be related to a gitea issue here.

@alexanderadam commented on GitHub (Nov 11, 2019): In that case I can't help you. But it still looks like a network error (because it says `connection refused` in your screenshot). I'm not sure whether the screen you showed here will also open Docker for the firewall. Because you need to open port `3000` ([see your other screenshot](https://github.com/go-gitea/gitea/issues/6939#issuecomment-552440795)) and your screenshot only shows something about opening the Docker socket over `2375`. And I guess it should be obvious that those don't have much to do with each other. Also your Ubuntu instance could have a firewall (`iptables` / `ufw`). So to summarize: no things you mentioned seem to be related to a gitea issue here.
Author
Owner

@BenMatheja commented on GitHub (Sep 26, 2020):

I'm having a similar issue, which i'm not able to work around.
I use gitea, drone and traefik (latest) and want to make the oauth2 flow working.
I'm able to request access to drone from gitea, but the final redirect fails with:

Login Failed. Post "https://git.<internaldomain>/login/oauth/access_token": dial tcp: lookup git.<internaldomain> on 127.0.0.11:53: no such host

It seems like drone is not able to resolve the internal domain for gitea from within the container in the last step.
This is my docker-compose configuration for drone.

 drone-server:
        image: drone/drone:latest
        volumes:
          - ./drone-data:/var/lib/drone/
          - /var/run/docker.sock:/var/run/docker.sock
        restart: always
        environment:
          - DRONE_SERVER_HOST=drone.<internaldomain>
          - DRONE_SERVER_PROTO=https
          - DRONE_LOGS_DEBUG=true
          #GITEA Settings
          - DRONE_GITEA_SERVER=https://git.<internaldomain>
          - DRONE_GITEA_CLIENT_ID=ers
          - DRONE_GITEA_CLIENT_SECRET=abc
          - DRONE_RPC_SECRET=def
        labels:
          - "traefik.enable=true"
          #  Router to forward Port 80 tto 443
          - "traefik.http.routers.drone80.rule=Host(`drone.<internaldomain>`)"
          - "traefik.http.routers.drone80.entrypoints=web"
          - "traefik.http.routers.drone80.middlewares=httpsredirect"
          - "traefik.http.middlewares.httpsredirect.redirectscheme.scheme=https"
          - "traefik.http.middlewares.httpsredirect.redirectscheme.permanent=true"
          #  Route which handles HTTPS Traffic
          - "traefik.http.services.drone.loadbalancer.server.port=80"
          - "traefik.http.services.drone.loadbalancer.server.scheme=http"
          - "traefik.http.routers.drone.tls=true"
          - "traefik.http.routers.drone.rule=Host(`drone.<internaldomain>`)"
          - "traefik.http.routers.drone.entrypoints=websecure"

And this one for Gitea

    gitea:
      image: gitea/gitea:latest
      environment:
        - USER_UID=1000
        - USER_GID=1000
        - DOMAIN=git.<internaldomain>
        - SSH_DOMAIN=git.<internaldomain>
      restart: always
      volumes:
        - ./gitea:/data
        - /etc/timezone:/etc/timezone:ro
        - /etc/localtime:/etc/localtime:ro
      ports:
        #- "3000:3000"
        - "222:22"
      labels:
        - "traefik.enable=true"
        #  Router to forward Port 80 tto 443
        - "traefik.http.routers.git80.rule=Host(`git.<internaldomain>`)"
        - "traefik.http.routers.git80.entrypoints=web"
        - "traefik.http.routers.git80.middlewares=httpsredirect"
        - "traefik.http.middlewares.httpsredirect.redirectscheme.scheme=https"
        - "traefik.http.middlewares.httpsredirect.redirectscheme.permanent=true"
        #  Route which handles HTTPS Traffic
        - "traefik.http.services.git.loadbalancer.server.port=3000"
        - "traefik.http.services.git.loadbalancer.server.scheme=http"
        - "traefik.http.routers.git.tls=true"
        - "traefik.http.routers.git.rule=Host(`git.<internaldomain>`)"
        - "traefik.http.routers.git.entrypoints=websecure"

Is there anything else to consider?
My Dockerhost is Ubuntu 18.04 without ufw applied. The internal domain is supplied via another pihole container on the same machine. Still the DNS is resolvable from the host

Edit: I could trace it down to internal DNS-Resolving not possible from the container. It seems I created a "chicken, egg" problem unresolvable (at least for me without deep knowledge of docker networking internals).
I worked around by procuring a "real" domain and added internal IPs to the A records. So the container can just resolve git.domain.com because everyone else would be able as well.

@BenMatheja commented on GitHub (Sep 26, 2020): I'm having a similar issue, which i'm not able to work around. I use gitea, drone and traefik (latest) and want to make the oauth2 flow working. I'm able to request access to drone from gitea, but the final redirect fails with: `Login Failed. Post "https://git.<internaldomain>/login/oauth/access_token": dial tcp: lookup git.<internaldomain> on 127.0.0.11:53: no such host` It seems like drone is not able to resolve the internal domain for gitea from within the container in the last step. This is my docker-compose configuration for drone. ```yaml drone-server: image: drone/drone:latest volumes: - ./drone-data:/var/lib/drone/ - /var/run/docker.sock:/var/run/docker.sock restart: always environment: - DRONE_SERVER_HOST=drone.<internaldomain> - DRONE_SERVER_PROTO=https - DRONE_LOGS_DEBUG=true #GITEA Settings - DRONE_GITEA_SERVER=https://git.<internaldomain> - DRONE_GITEA_CLIENT_ID=ers - DRONE_GITEA_CLIENT_SECRET=abc - DRONE_RPC_SECRET=def labels: - "traefik.enable=true" # Router to forward Port 80 tto 443 - "traefik.http.routers.drone80.rule=Host(`drone.<internaldomain>`)" - "traefik.http.routers.drone80.entrypoints=web" - "traefik.http.routers.drone80.middlewares=httpsredirect" - "traefik.http.middlewares.httpsredirect.redirectscheme.scheme=https" - "traefik.http.middlewares.httpsredirect.redirectscheme.permanent=true" # Route which handles HTTPS Traffic - "traefik.http.services.drone.loadbalancer.server.port=80" - "traefik.http.services.drone.loadbalancer.server.scheme=http" - "traefik.http.routers.drone.tls=true" - "traefik.http.routers.drone.rule=Host(`drone.<internaldomain>`)" - "traefik.http.routers.drone.entrypoints=websecure" ``` And this one for Gitea ```yaml gitea: image: gitea/gitea:latest environment: - USER_UID=1000 - USER_GID=1000 - DOMAIN=git.<internaldomain> - SSH_DOMAIN=git.<internaldomain> restart: always volumes: - ./gitea:/data - /etc/timezone:/etc/timezone:ro - /etc/localtime:/etc/localtime:ro ports: #- "3000:3000" - "222:22" labels: - "traefik.enable=true" # Router to forward Port 80 tto 443 - "traefik.http.routers.git80.rule=Host(`git.<internaldomain>`)" - "traefik.http.routers.git80.entrypoints=web" - "traefik.http.routers.git80.middlewares=httpsredirect" - "traefik.http.middlewares.httpsredirect.redirectscheme.scheme=https" - "traefik.http.middlewares.httpsredirect.redirectscheme.permanent=true" # Route which handles HTTPS Traffic - "traefik.http.services.git.loadbalancer.server.port=3000" - "traefik.http.services.git.loadbalancer.server.scheme=http" - "traefik.http.routers.git.tls=true" - "traefik.http.routers.git.rule=Host(`git.<internaldomain>`)" - "traefik.http.routers.git.entrypoints=websecure" ``` Is there anything else to consider? My Dockerhost is Ubuntu 18.04 without ufw applied. The internal domain is supplied via another pihole container on the same machine. Still the DNS is resolvable from the host **Edit:** I could trace it down to internal DNS-Resolving not possible from the container. It seems I created a "chicken, egg" problem unresolvable (at least for me without deep knowledge of docker networking internals). I worked around by procuring a "real" domain and added internal IPs to the A records. So the container can just resolve git.domain.com because everyone else would be able as well.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#3327