Token handling in post requests to the api

Drone Support
1

Hello,

we have built two integrations with Drone where we are creating builds via Build Create | Drone.

For a long time we’ve been having issues after gitea/drone updates/restarts:
Our post request just returned an empty response. To make it work again, the user whose DRONE_TOKEN we are using had to relogin, but we did not understand why that helped.

When it recently occured again, a colleague noticed that it was actually a 302 response with a Location header redirecting to gitea for an oauth2 flow. curl did not follow that because apparently redirects in POST requests are invalid. After the colleague did an arbitrary GET request, it seemed to work again, probably because there redirects were followed and the oauth2 flow was completed.

We now introduced a GET request to the API before the actual POST request, just to trigger the oauth2 flow once first.

Is this how we should do it? Which is the most lightweight GET request we can use?
If the drone token is the only thing we need to provide to drone to be able to trigger the flow and there are obviously no cookies or anything else involved, why can’t drone handle it server side and have the POST requests work without prior get request?

I’m sorry if my descriptions are a bit vague but I cannot reproduce the issue on demand.

Fwiw I have checked drone-js, drone-node and drone-go and couldn’t find any specific redirect or post request handling anywhere, so I assume all these implementations suffer from the same issue.

Thanks in advance
Dominik

2

Have you reached out to the Gitea community and asked for help? This sounds like a Gitea configuration issue (for example, maybe you just need to disable Gitea token expiration in the configuration). We don’t have any problems with our other providers that use oauth2 (GitHub, GitLab, etc). Gitea has also made a number of breaking changes to their authentication and token implementations over the past year which has caused problems for Gitea users, especially after upgrades.

3

I mean, yes, tokens expiring (or whatever) seems to be a Gitea issue of some sort.
But the redirect on POST request is coming from Drone, no?

4

When it recently occured again, a colleague noticed that it was actually a 302 response with a Location header redirecting to gitea for an oauth2 flow.

If I correctly understand the problem, redirecting an API call to a login screen sounds like a Gitea bug. They should be returning an http error code and a JSON response body for us to parse, similar to what the other providers are doing. For example, this is how Bitbucket responds to an expired token:

{“type”: “error”, “error”: {“message”: “Access token expired. Use your >refresh token to obtain a new access token.”}}

But the redirect on POST request is coming from Drone, no?

I am not aware of any scenarios where Drone redirects, except for when you configure https, but you attempt to use the http address instead. When https is enabled, Drone auto-redirects all http requests to https. Also, Drone only redirects using the 303 status code (see other), it never redirects using a 302 status code.