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

Admin user registration and EMAIL_DOMAIN_ALLOWLIST #27457

Closed
TineHorvat opened this issue Oct 5, 2023 · 9 comments · Fixed by #29522
Closed

Admin user registration and EMAIL_DOMAIN_ALLOWLIST #27457

TineHorvat opened this issue Oct 5, 2023 · 9 comments · Fixed by #29522
Labels

Comments

@TineHorvat
Copy link

Description

Hello,
we have a local installation of Gitea and have recently upgraded to 1.20.4 and experienced a feature or functionality that was not present before on in the versions before. I can see there was a security enchantment (https://github.com/go-gitea/gitea/releases/tag/v1.20.4) about checking the blocklist.

The issue:
After the upgrade to 1.20.4 we are not able (through administrator dashboard) to add users that have emails on domains that are not listed on the ALLOWLIST. If you use the any other domain, we get the error message: "The email address is invalid."

We have user registration enabled, and set EMAIL_DOMAIN_ALLOWLIST for our organization and some business partners domains, which is working fine and they can register trough the form. For any other domains, only Gitea administrators added new users, so we can avoid spam users as much as possible. This was working for any domains, also those that are not on the ALLOWLIST in the previous version of Gitea.

We want to keep the "open" registration for the domains that are allowed, but also allow the administrators to add users with emails from any other domains. The main reason is we don't want to disable the registration for "our" domains because those users are under our organization policy and they can register by themself, but still be able that admins can add users with any domain if needed.

Is there a new configuration combination that allows this settings or is this a "feature/bug", that checks only the ALLOWLIST also when an administrator is adding a new user?

Can you please look into in?

Thanks,
Tine

Gitea Version

1.20.4

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

We are running on Windows Server, its running as a windows service.

Database

None

@Zettat123
Copy link
Contributor

Since #26812 is a security enhancement, I think this is not a bug but an expected behavior. As for your requirement, maybe we can add an option/configuration to allow administrators to manually add users whose emails are not in the ALLOWLIST. But I'm not sure if we should provide such a feature.

@Zettat123 Zettat123 added type/proposal The new feature has not been accepted yet but needs to be discussed first. and removed type/bug labels Oct 12, 2023
@TineHorvat
Copy link
Author

Hey Zettat123,
I saw that it was added as a security enhancement, but I was not sure if this was also intended for the administration of Gitea users or just the registration process. That's why I marked it as a kinda bug.

I am also not sure what could be the issue for the administrators to be still able to add users with emails which are not on EMAIL_DOMAIN_ALLOWLIST as they are manually adding them by hand. Since this was working for years and never had a single issue with this process.

This is more of a bypass or workaround, but what could happen if we add users with a "bogus" e-mails with a domain on allowlist and then change the records in the database? This is the worst scenario which we don't want to use, but still, this could work without issues?

@f403
Copy link

f403 commented Dec 6, 2023

@Zettat123 , I would consider this a bug.

According to the documentation:
EMAIL_DOMAIN_ALLOWLIST: If non-empty, comma separated list of domain names that can only be used to register on this instance, wildcard is supported.

It has been designed for providing self-registration for some users and manual (by admins) registration for others.
Forbidding administrators to create user will either limit usability of the instance, or create security breaches if admins will try to edit the database.

@TineHorvat , please be aware:

  1. there are two table you might want to modify (user and email_address)
  2. if you update email directly in the database, you won't be able to modify/restrict/disable this user via admin GUI

@stdmr
Copy link

stdmr commented Dec 27, 2023

@Zettat123 , I would consider this a bug.
It has been designed for providing self-registration for some users and manual (by admins) registration for others. Forbidding administrators to create user will either limit usability of the instance, or create security breaches if admins will try to edit the database.

Exactly! Thank you! I think the main use-case for EMAIL_ALLOW_LIST is to restrict user self registration.

Maybe just show a warning for admins, when registering an email which is not in the EMAIL_ALLOW_LIST.

@Zettat123
Copy link
Contributor

Zettat123 commented Feb 29, 2024

Thanks for all your comments. After discussion I think admins should be able to create any user manually regardless of whether the user's email address is in the EMAIL_DOMAIN_ALLOWLIST or not. This should be a bug.

@Zettat123 Zettat123 added type/bug and removed type/proposal The new feature has not been accepted yet but needs to be discussed first. labels Feb 29, 2024
@gilbertoca
Copy link

gilbertoca commented Feb 29, 2024

@lunny @Zettat123
I'm here as well because of this problem. In my case, our users come from some smtp servers and I have to change the "Maximum Number of Repositories" to ZERO - every time a new user comes in - see the print-screen #19582

@Zettat123
Copy link
Contributor

Hi @gilbertoca . I've seen the print-screen. I think your problem is that you get a "The email address is invalid" error when you change the "Maximum Number of Repositories".

Is the EMAIL_DOMAIN_ALLOWLIST configuration of your Gitea instance is empty? Could you add your email domain (like ibrowser.net.br) to the allowlist and then check if you can successfully change the "Maximum Number of Repositories"?

After testing, we will be able to know if the error is caused by the EMAIL_DOMAIN_ALLOWLIST configuration.

@f403
Copy link

f403 commented Mar 1, 2024

Admin is not able to change any settings of a user, if the user's email host is not in EMAIL_DOMAIN_ALLOWLIST.
This also includes "Maximum Number of Repositories" and other important properties like "Disable Sign-In".
Checked on 1.21.5.
Changing user's avatar works :)

@gilbertoca
Copy link

gilbertoca commented Mar 1, 2024

Hi @gilbertoca . I've seen the print-screen. I think your problem is that you get a "The email address is invalid" error when you change the "Maximum Number of Repositories".

Is the EMAIL_DOMAIN_ALLOWLIST configuration of your Gitea instance is empty? Could you add your email domain (like ibrowser.net.br) to the allowlist and then check if you can successfully change the "Maximum Number of Repositories"?

After testing, we will be able to know if the error is caused by the EMAIL_DOMAIN_ALLOWLIST configuration.

@Zettat123 @lunny
I can confirm this behavior. I've just added this domain in the EMAIL_DOMAIN_ALLOWLIST and now I can change the Maximum Number of Repositories

We have about six smtp as Authentication Source. I have to add all of them in the EMAIL_DOMAIN_ALLOWLIST and stop/start the service.
I think this is counterintuitive usage for admins!

lunny pushed a commit that referenced this issue Mar 5, 2024
Fix #27457

Administrators should be able to manually create any user even if the
user's email address is not in `EMAIL_DOMAIN_ALLOWLIST`.
Zettat123 added a commit to Zettat123/gitea that referenced this issue Mar 5, 2024
…#29522)

Fix go-gitea#27457

Administrators should be able to manually create any user even if the
user's email address is not in `EMAIL_DOMAIN_ALLOWLIST`.
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 16, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants