search

go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
44.96k stars 5.48k forks source link

Disable password logins when oauth2 is used #25393

Open luna-duclos opened 1 year ago

luna-duclos commented 1 year ago

Feature Description

It would be great if gitea would allow me to disable password changes for users who's account has been created via an oauth2 login and disallow them to login using it even if they had set it.

As well as hide the relevant components of the web UI.

a PR for this was made in the past: #19344, but it seems it was closed without review. I was wondering if it would be something that is ok to potentially recontribute ?

Screenshots

No response

lunny commented 1 year ago

Should that be an option of this OAuth2 source setting?

silverwind commented 1 year ago

Has to be a global config option I assume as there can be multiple oauth sources etc. Also, it is quite a risky thing because if oauth provider is down, not even admin can log in.

wxiaoguang commented 1 year ago

I do not think this issue can be resolved by "easy" patches.

See

The first step IMO is to have a (nearly) complete design,to define the expected behaviors for various situations.

luna-duclos commented 1 year ago

Has to be a global config option I assume as there can be multiple oauth sources etc. Also, it is quite a risky thing because if oauth provider is down, not even admin can log in.

As long as its an app.ini setting, whoever administers the instance could disable it again to log in as admin again, no ?

jaltgen commented 5 months ago

I'd be in favor of this as well, Portainer has this option in the GUI, for example 👍 I understand it may not fit in the current scope of work or schedule, its just one of those small things that may increase security and make adoption with organisations easier?

gtherond commented 2 months ago

I'd like to second this as we exactly use that with our on-premise coder (coder.com) instance and it works like a bliss as we can still enable back the password based login by just switching back the environment variable to its default value.

This allows us (as long as with the disabled signup feature) to tightly control who access and sign in the forge.

Additionally, we're using a kubernetes deployment so switching back some env vars is swift and smooth without any visible interrupt for our users.