Stable oauth2.JWT_SECRET #106

New Issue

viceice · 2021-01-28T05:27:11Z

viceice commented

2021-01-28 05:27:11 +00:00

The oauth2.JWT_SECRET should be stable.

Currently it will be regenerated on each container restart. So all existing token are invalid then.

https://discourse.gitea.io/t/drone-auth-error-after-gitea-server-restart/2880/4

The `oauth2.JWT_SECRET` should be stable. Currently it will be regenerated on each container restart. So all existing token are invalid then. https://discourse.gitea.io/t/drone-auth-error-after-gitea-server-restart/2880/4

viceice commented

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

Maybe related to #43

luhahn commented

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

Well, you can always define the oauth token yourself.
The same goes for #43. Should be stable if you've defined one :)

gitea:
  config:
    oauth2:
      JWT_SECRET: <your_secret>
    security:
      INTERNAL_TOKEN: <token>

Well, you can always define the oauth token yourself. The same goes for #43. Should be stable if you've defined one :) ```yaml gitea: config: oauth2: JWT_SECRET: <your_secret> security: INTERNAL_TOKEN: <token> ```

viceice commented

2021-02-09 08:45:11 +00:00

Sure, but the JWT_SECRET must have a specific structure, otherwise it will be overwritten on every gitea startup

0cd87d64ff/modules/setting/setting.go (L760)

Seems need exacly 32 bytes (then base64 encoded)

fe79b13ab2/modules/generate/generate.go (L60-L68)

Sure, but the `JWT_SECRET` must have a specific structure, otherwise it will be overwritten on every gitea startup https://github.com/go-gitea/gitea/blob/0cd87d64ff8bb40520877d3a217363de299f4531/modules/setting/setting.go#L760 Seems need exacly 32 bytes (then base64 encoded) https://github.com/go-gitea/gitea/blob/fe79b13ab2ce9526fae10a5257b4e171cae30ecb/modules/generate/generate.go#L60-L68

justusbunsi commented

2021-06-17 19:53:43 +00:00

Maybe we could create those tokens (internal token, jwt_secret, secret_key) prior to the actual run. There are gitea cli commands to do that. We could even dynamically create a Kubernetes secret storing these values for the future. This would requires access to the Kubernetes API which could be done using a serviceaccount with the necessary permissions (e.g. update a specific secret that is created with the helm chart rollout in the cluster).

Doing so would persist those data in a secure way so that they can be reused.

What do you think @luhahn?

Maybe we could create those tokens (internal token, jwt_secret, secret_key) prior to the actual run. There are gitea cli commands to do that. We could even dynamically create a Kubernetes secret storing these values for the future. This would requires access to the Kubernetes API which could be done using a serviceaccount with the necessary permissions (e.g. update a specific secret that is created with the helm chart rollout in the cluster). Doing so would persist those data in a secure way so that they can be reused. What do you think @luhahn?

justusbunsi commented

2021-11-12 17:04:01 +00:00

I am sure this issue will be fixed with #239, once ready.

❤️ 1

justusbunsi added the

kind

bug

label 2021-11-13 12:38:17 +00:00

justusbunsi referenced a pull request that will close this issue

2021-11-20 11:33:14 +00:00

Rework app.ini generation #239

justusbunsi closed this issue