Skip to content
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

Closed
wants to merge 19 commits into from

Conversation

pboguslawski
Copy link
Contributor

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

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
@pboguslawski
Copy link
Contributor Author

This is #13068 updated to current main.

@GiteaBot GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Jan 30, 2022
@@ -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 {
Copy link
Contributor

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

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 {
Copy link
Contributor

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.

Copy link
Contributor Author

@pboguslawski pboguslawski Feb 2, 2022

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).

// 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) {
Copy link
Contributor

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)

Suggested change
if setting.Service.DisableLocalUserManagement && (u.Type == UserTypeIndividual) {
if setting.Service.DisableLocalUserManagement && u.Type == UserTypeIndividual {

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 25673a9.

@@ -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) {

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 25673a9.

@@ -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) {

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change

@CirnoT
Copy link
Contributor

CirnoT commented Feb 1, 2022

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".

@pboguslawski
Copy link
Contributor Author

pboguslawski commented Feb 2, 2022

What is the reasoning and desired use-case of this configuration?

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.

Why anyone would want to explicitly configure this option (potentially when there are existing local users)?

There are no local users in described scenarios.

In addition, why would this configuration option disable access to configuration of new external sources?

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).

@CirnoT
Copy link
Contributor

CirnoT commented Feb 2, 2022

There are no local users in described scenarios.

But there can be, isn't that right? For example after installation initial administrator is local one.

@pboguslawski
Copy link
Contributor Author

pboguslawski commented Feb 2, 2022

But there can be, isn't that right?

Sure; system owner (not gitea developer) should be allowed to decide to enable/disable access to local user management with DISABLE_LOCAL_USER_MANAGEMENT; that's what this PR is for.

For example after installation initial administrator is local one.

Only if is created during installation. Installation using cli fortunatelly does not force it.

@codecov-commenter
Copy link

Codecov Report

Merging #18466 (2691234) into main (3349fd8) will decrease coverage by 0.00%.
The diff coverage is 18.39%.

Impacted file tree graph

@@            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     
Impacted Files Coverage Δ
routers/web/admin/emails.go 0.00% <0.00%> (ø)
routers/web/admin/users.go 39.18% <0.00%> (-1.23%) ⬇️
routers/web/user/setting/account.go 25.38% <0.00%> (-2.10%) ⬇️
routers/web/user/setting/profile.go 36.22% <0.00%> (-0.28%) ⬇️
services/auth/source/ldap/source_authenticate.go 46.29% <0.00%> (ø)
services/auth/source/ldap/source_sync.go 37.06% <0.00%> (ø)
services/forms/user_form.go 40.90% <ø> (ø)
models/user/user.go 60.10% <20.00%> (-2.45%) ⬇️
routers/web/admin/auths.go 44.88% <33.33%> (-2.84%) ⬇️
modules/setting/service.go 76.40% <100.00%> (+0.26%) ⬆️
... and 67 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3349fd8...2691234. Read the comment docs.

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
@pboguslawski
Copy link
Contributor Author

pboguslawski commented Feb 4, 2022

Fixed problem with prohibition and extra e-mails when local user management is disabled:

e45a831
38e5a4d

Fixes: e45a831
Related: go-gitea#18466
Author-Change-Id: IB#1105051
@stale
Copy link

stale bot commented Apr 17, 2022

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.

@stale stale bot added the issue/stale label Apr 17, 2022
@wxiaoguang
Copy link
Contributor

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 if blocks .... really fragile.

A whole page could be hidden totally if a feature is disabled, but hiding UI elements again and again seems whack-a-mole game.

@wxiaoguang wxiaoguang closed this May 10, 2023
@pboguslawski
Copy link
Contributor Author

pboguslawski commented May 20, 2023

I think it could be closed.

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.

I also agree that usually it should avoid "hiding" UI details, which makes the UI fragile and difficult to test.

So you leave bugs just to avoid difficult testing?

A whole page could be hidden totally if a feature is disabled

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.

@wxiaoguang
Copy link
Contributor

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.

@pboguslawski
Copy link
Contributor Author

it needs a complete refactoring

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.

@wxiaoguang
Copy link
Contributor

I opened a summary issue to track the problem: [Summary] Improve auth source / login system #24821

(it's really complicated ....)

@go-gitea go-gitea locked as resolved and limited conversation to collaborators Aug 8, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
issue/stale lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants