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

Closed
opened 2020-10-09 01:01:21 +00:00 by sanigo · 4 comments
sanigo commented 2020-10-09 01:01:21 +00:00 (Migrated from gitea.com)

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 (Migrated from gitea.com)

Is this Issue still relevant?

Is this Issue still relevant?
justusbunsi commented 2021-06-26 10:34:23 +00:00 (Migrated from gitea.com)

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 (Migrated from gitea.com)

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

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 (Migrated from gitea.com)

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.

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.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: lunny/helm-chart#43
No description provided.