How is openid_connect_signing_key handled? #2912
Comments
ebarped
added a commit
to ebarped/docker-gitlab
that referenced
this issue
Mar 6, 2024
…ackup/restore & restarts without errors
ebarped
added a commit
to ebarped/docker-gitlab
that referenced
this issue
Mar 7, 2024
…backup/restore & restarts without errors'
ebarped
added a commit
to ebarped/docker-gitlab
that referenced
this issue
Mar 7, 2024
…backup/restore & restarts without errors'
|
Resolved in #2913 |
ebarped
added a commit
to ebarped/docker-gitlab
that referenced
this issue
Mar 7, 2024
…backup/restore & restarts without errors'
ebarped
added a commit
to ebarped/docker-gitlab
that referenced
this issue
Mar 7, 2024
…backup/restore & restarts without errors'
ebarped
added a commit
to ebarped/docker-gitlab
that referenced
this issue
Mar 7, 2024
…backup/restore & restarts without errors'
ebarped
added a commit
to ebarped/docker-gitlab
that referenced
this issue
Mar 7, 2024
…backup/restore & restarts without errors'
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Same as #2420, we should add support for
openid_connect_signing_keyinside secrets file. If we dont have support for specifying it as an env var previous to the runtime, each restart will generate a new key, and errors in 2FA, settings, webhooks, MR... etc will happen.Also, the users would not be able to restore from a backup, since this key will change.
The text was updated successfully, but these errors were encountered: