OAuth err with gitea, when run agola for days

  • err in frontPage’s message
cannot get oauth2 token: oauth2: cannot fetch token: 400 Bad Request Response: {"error":"unauthorized_client","error_description":"client is not authorized"}
  • err in agola:
agola_1  | 2020-01-15T10:04:10.970Z	ERROR	api/oauth2.go:44	err: cannot get oauth2 token:
agola_1  |     agola.io/agola/internal/gitsources/gitea.(*Client).RequestOauth2Token
agola_1  |         /agola/internal/gitsources/gitea/gitea.go:146
agola_1  |   - oauth2: cannot fetch token: 400 Bad Request
agola_1  | Response: {"error":"unauthorized_client","error_description":"client is not authorized"}

agola_1  | 2020-01-14T15:02:26.382Z	INFO	action/user.go:433	updating user "sam" linked account
agola_1  | 2020-01-14T15:02:26.414Z	INFO	action/user.go:438	linked account "6a753830-xxx-3c92a20a74b4" for user "sam" updated
  • then I try restart: etcd, agola. OAuth turns to work:

oauth_ok

{"request_type":"loginuser","response":{"oauth2_redirect":"","token":"eyJhbGciO.xx.u1npjfmgg","user":{"id":"909a8xxx-719c6d6e17e3","username":"sam","tokens":["directrun"],"linked_accounts":[{"id":"6a753830-xxxc92a20a74b4","remote_source_id":"6ea611xxx-76e51ff46dc8","remote_user_name":"sam","remote_user_avatar_url":""}]}}}

My gitea version 1.10.0+dev-396-gdd611c9a8

I confirm this issue.
I had to restart agola (but no etcd) to correctly log in via the UI.

I also confirm this issue.

Did you find a workaround ?

I cannot reproduce it here but looks like for some reasons we are passing a wrong/empty client id/secret to gitea. If this is fixed by just restarting agola it problably means that some calls between the gateway and the configstore are failing or returning wrong data. Can you please check your logs to see if there’re some errors related to configstore when trying to authenticate?

Additionally can you try to get the remote source using the agola cli and see if this works and if so try to call the configstore endpoint on http://${configstoreip}:${configstoreport}/remotesources/${REMOTESOURCENAME} to see if it returns a valid answer containing the client id and secret you defined in the remote source when creating it?

Thanks for your input.

Unfortunately, after a compose-down, remove of volume and restarting, I could not reproduce it.

If it happens again, I will try to pin point the problem with your input.