-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DISABLE_LOCAL_USER_MANAGEMENT mode added #18466
Conversation
Added parameter DISABLE_LOCAL_USER_MANAGEMENT (false by default) in app.ini [service] section; when true disables local modifications of username, fullname and e-mail fields in user Settings. Author-Change-Id: IB#1105051
This patch blocks access to local user management options that are not required and possibly problematic in scenario when users are managed in external database (like LDAP) and should not be managed separately in gitea. Options specific to gitea (like restricted users) are still managed in this app. Author-Change-Id: IB#1105051
This fixes external user syncing when local user management is disabled. Fixes: eca3563 Author-Change-Id: IB#1105051
Hide message about changing username when local user modifications are disabled. Author-Change-Id: IB#1105051
Adopted repos screens didn't hide menu tabs. This mod fixes it and simplifies configuration for templates. It also removes unnecessarry comment. Author-Change-Id: IB#1105051 Fixes: eca3563
Fixes 500 on organization name change in DISABLE_LOCAL_USER_MANAGEMENT mode. Fixes: eca3563 Author-Change-Id: IB#1105051
This is #13068 updated to current main. |
models/user/user.go
Outdated
@@ -872,16 +908,21 @@ func UpdateUser(u *User, emailChanged bool) error { | |||
} | |||
|
|||
// UpdateUserCols update user according special columns | |||
func UpdateUserCols(ctx context.Context, u *User, cols ...string) error { | |||
return updateUserCols(db.GetEngine(ctx), u, cols...) | |||
func UpdateUserCols(ctx context.Context, u *User, force bool, cols ...string) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd mostly see that force = false, I think it's better if the exported function doesn't have this as a argument but rather a new function UpdateForceUserCols
, the unexported function is fine to have such argument IMO
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
Fixes: f92d339 Related: go-gitea#18466 (comment) Author-Change-Id: IB#1105051
func updateUserAllowed(u *User) error { | ||
// Don't allow changes of selected user fields if local user management is disabled. | ||
if setting.Service.DisableLocalUserManagement && (u.Type == UserTypeIndividual) { | ||
if currUser, err := GetUserByID(u.ID); err == nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More a nitpick: first check if err != nil
to then return err
so we can avoid a extra indent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Current syntax is ok (currUser
is defined only for if
scope).
models/user/user.go
Outdated
// updateUserAllowed is used to block updating selected user fields when local user managemement is disabled. | ||
func updateUserAllowed(u *User) error { | ||
// Don't allow changes of selected user fields if local user management is disabled. | ||
if setting.Service.DisableLocalUserManagement && (u.Type == UserTypeIndividual) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The linter doesn't like unnecessary parentheses(issue is also present in other places in this PR)
if setting.Service.DisableLocalUserManagement && (u.Type == UserTypeIndividual) { | |
if setting.Service.DisableLocalUserManagement && u.Type == UserTypeIndividual { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in 25673a9.
routers/web/admin/emails.go
Outdated
@@ -109,6 +116,13 @@ func isKeywordValid(keyword string) bool { | |||
|
|||
// ActivateEmail serves a POST request for activating/deactivating a user's email | |||
func ActivateEmail(ctx *context.Context) { | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in 25673a9.
routers/web/admin/emails.go
Outdated
@@ -109,6 +116,13 @@ func isKeywordValid(keyword string) bool { | |||
|
|||
// ActivateEmail serves a POST request for activating/deactivating a user's email | |||
func ActivateEmail(ctx *context.Context) { | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the reasoning and desired use-case of this configuration? Instance can be have users from mixed sources and external sources are not editable already. Why anyone would want to explicitly configure this option (potentially when there are existing local users)? In addition, why would this configuration option disable access to configuration of new external sources? As far as I am aware they have nothing to do with "local user management". |
To allow use gitea in corpo environments where user db is centrally managed (i.e. user data, e-mail in LDAP) and authenticated using reverse proxy (SSO with or without passwords) and local admin should not try to create nor change user data in the app itself.
There are no local users in described scenarios.
Because in environments as above there is fixed number of user backends and after initial config there should be a switch to disable changes to avoid mistakes. Backend configuration should be moved from DB to app.ini IHMO but that's another (already discussed topic). |
Related: go-gitea#18466 (review) Author-Change-Id: IB#1105051
But there can be, isn't that right? For example after installation initial administrator is local one. |
Sure; system owner (not gitea developer) should be allowed to decide to enable/disable access to local user management with
Only if is created during installation. Installation using cli fortunatelly does not force it. |
Fixes: cda4a8a Related: go-gitea#18466 Author-Change-Id: IB#1105051
Codecov Report
@@ Coverage Diff @@
## main #18466 +/- ##
==========================================
- Coverage 46.03% 46.03% -0.01%
==========================================
Files 840 846 +6
Lines 92856 93275 +419
==========================================
+ Hits 42746 42937 +191
- Misses 43323 43519 +196
- Partials 6787 6819 +32
Continue to review full report at Codecov.
|
When local user management is disabled, active user login should not be prohibited. Only primary user e-mail should be available when local user management is enabled (only this mail is synchronized from LDAP). Related: go-gitea#18466 Author-Change-Id: IB#1105051
Fixes: e45a831 Related: go-gitea#18466 Author-Change-Id: IB#1105051
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 months. Thank you for your contributions. |
It has been stale for a long time, I think it could be closed. ps: I also agree that usually it should avoid "hiding" UI details, which makes the UI fragile and difficult to test. Especially for this PR, a lot of logic couldn't be tested easily, and there are too many A whole page could be hidden totally if a feature is disabled, but hiding UI elements again and again seems whack-a-mole game. |
Allowing local user management when using external user backend makes no sense and should not be ignored but fixed. Consider creating separate issue if you don't like proposed solution.
So you leave bugs just to avoid difficult testing?
No because it contains user gitea specific settings also. Only data coming from external must not be changed in gitea. Feel free to adapt to your vision but please don't ignore such shortcoming - should be fixed if gitea wants to be serious solution for enterprise environments. |
There are too many legacy problem for the auth system, not only this "disable DISABLE_LOCAL_USER_MANAGEMENT", but also includes: Enforce 2FA, default login source (OAuth/SAML), etc. Without a complete design, the simple "patches" would conflict in the end, and would cause security problems for end users. So, it needs a complete refactoring, I might start the work in 1.21. |
Agree. Glad to hear there are plans to fix it. If you know any open issue regarding it - may be worth to link it here. |
I opened a summary issue to track the problem: [Summary] Improve auth source / login system #24821 (it's really complicated ....) |
Added parameter DISABLE_LOCAL_USER_MANAGEMENT (false by default) in
app.ini [service] section; when true blocks access to local user
management options that are not required and possibly problematic
in scenario when users are managed in external database (like LDAP)
and should not be managed separately in gitea. Options specific
to gitea (like restricted users) are still managed in this app.
This mod disables local management for all users in gitea not only
users created from specific backend (i.e. LDAP).
Author-Change-Id: IB#1105051