I’m now having issues trying to get my Drone installation to use Oauth2 using the latest gitea docker image, and using drone version drone/drone:1.3.1. I’ve created the application and callback in gitea, and created new variables in the docker image for client_id & client_secret.
When logging into drone for the first time, I’m sent to my gitea installation to accept the connection and once I’ve enabled it, I’m redirected to drone with the message of unauthorized_client.
I’ve checked forums repeatedly but not managed to get anything that works yet, Any help would be appreciated
All of these keys and IDs and whatnot won’t be relevant by the time this is posted so I don’t view them as a security risk. That key it can’t exchange isn’t anything I’ve specified, so I’m guessing it’s something else generated during the oAuth sequence. I know Gitea has recently changed how it does some oAuth stuff. Wondering if this is a straight-up bug in Drone.
Success! It turned out that my client secret had an equals sign at the end, and the parser I was using to read it in was stripping that last equals. When the secret was passed back to Gitea, it didn’t match and I got the unauthorized_client error.
@bajmhunter Check your DRONE_GITEA_CLIENT_ID and DRONE_GITEA_CLIENT_SECRET values being passed to the Drone Docker instance. Ensure that they exactly match what’s in your Gitea control panel for the Drone application.
I’ve had a look and seems that’s exactly whats happening on my end too. @GregJPreece how did you manage to set it to accept the equals sign at the end of the secret? Or is it easiest to regenerate until you receive one without the equals?
However, I do not think this is a good approach in the long run. Aside from from not being very Docker-y, this leaves secrets lying around in a props file that then has to be managed, and also passes them in as container env variables, which is a bit of a security issue. This was just what I was using for my initial experience. I am in the process of transferring the Bash script into a docker-compose.yml file, and handing the Gitea credentials to the Drone container via Docker Secrets. I think once I have it running, it’s likely to turn into a blog post. Perhaps @bradrydzewski would find that useful for the tutorial series they’re looking to create?
Thanks for that, I’ve checked but when its parsed into the docker start script its parsing successfully. I mis-understood and thought it was a parse issue when it was connecting to the gitea instance.
I currently use unRaid as my docker host, and on each one after examining the logs and boot sequences, both are loading any required parameters and variables in exactly as they should.
But for some reason, Ive just gone and built a new server and have started Gitea & Drone from scratch but still seem to get the issue. Although now I cant seem to find any major issues in the log, but still detected as an unauthorized client
Is there any way to use the old auth method, rather than the oauth2?