go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
45.19k stars 5.5k forks source link

drone not able to auth via oauth2 #6939

Closed vtolstov closed 5 years ago

vtolstov commented 5 years ago

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 
DblK commented 5 years ago

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

vtolstov commented 5 years ago

All works fine now

PhilsLab commented 5 years ago

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?

sleepycodernotes commented 5 years ago

pump

alexanderadam commented 5 years ago

@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://user-images.githubusercontent.com/372620/68589263-be6cfb80-048b-11ea-8e87-a5c10f7bc20c.png)

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

sleepycodernotes commented 5 years ago

image

sleepycodernotes commented 5 years ago

Using latest images : gitea/drone/treafik/portainer

alexanderadam commented 5 years ago
  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?
sleepycodernotes commented 5 years ago
  1. i did
  2. i'm using windows 10 wsl 2, dont know where to look
alexanderadam commented 5 years ago
  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.
sleepycodernotes commented 5 years ago

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

alexanderadam commented 5 years ago

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.

BenMatheja commented 4 years ago

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.