Gitea chart will recreate INTERNAL_TOKEN every 21:51/52 GMT if the token is defined before installing. #43

New Issue

sanigo · 2020-10-09T01:01:21Z

sanigo commented

2020-10-09 01:01:21 +00:00

I installed gitea chart, to find out that repository would refuse pushes every day until restarting service, and there is a 403 error about accessing /api/internal while pushing.
After digging into the pod installation, I figured out that the INTERNAL_TOKEN was changed arround every 21:51 GMT without restarting the service. So the pre-receive hook will use a new internal_token to access /api/internal while the token is not usable yet.

To reproduce, you can install the gitea chart without setting INTERNAL_TOKEN/SECRET_KEY in values.yaml.

I am not familiar with golang and gitea code, but I am curious about the code that causes the problem.

I installed gitea chart, to find out that repository would refuse pushes every day until restarting service, and there is a 403 error about accessing /api/internal while pushing. After digging into the pod installation, I figured out that the INTERNAL_TOKEN was changed arround every 21:51 GMT without restarting the service. So the pre-receive hook will use a new internal_token to access /api/internal while the token is not usable yet. To reproduce, you can install the gitea chart without setting INTERNAL_TOKEN/SECRET_KEY in values.yaml. I am not familiar with golang and gitea code, but I am curious about the code that causes the problem.

luhahn commented

2021-01-21 14:44:42 +00:00

Is this Issue still relevant?

viceice referenced this issue

2021-01-28 05:30:16 +00:00

Stable oauth2.JWT_SECRET #106

luhahn referenced this issue

2021-02-09 08:39:21 +00:00

Stable oauth2.JWT_SECRET #106

justusbunsi commented

2021-06-26 10:34:23 +00:00

I figured out that the INTERNAL_TOKEN was changed arround every 21:51 GMT without restarting the service.

Sounds like an internal cronjob running at that time. Can you find out which one is fired around that time?

> I figured out that the INTERNAL_TOKEN was changed arround every 21:51 GMT without restarting the service. Sounds like an internal cronjob running at that time. Can you find out which one is fired around that time?

justusbunsi commented

2021-11-12 17:26:54 +00:00

If this is an issue with the Helm Chart and not with an internal cronjob as thought, it will probably be fixed with #239.

justusbunsi commented

2021-11-20 12:05:21 +00:00

Closing this for now. As mentioned above, with 5.0.0 both values will be persistent on new installs. Please open a new issue or repoen this if you have similar issues in the future.

justusbunsi closed this issue

2021-11-20 12:05:28 +00:00

Sign in to join this conversation.

No Milestone

No Assignees

3 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: gitea/helm-chart#43