Skip to content

Relax email validation #17029

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

Closed
metov opened this issue Sep 13, 2021 · 5 comments
Closed

Relax email validation #17029

metov opened this issue Sep 13, 2021 · 5 comments

Comments

@metov
Copy link

metov commented Sep 13, 2021

When adding emails for a user under Settings -> Account -> Manage Email Addresses, Gitea 1.12.1 applies an email validation. If the address given doesn't satisfy gitea, it issues

email_error = ` is not a valid email address.`
.

It seems like part of the validation is to require a . in the domain, so for example johndoe@homepc will be considered "invalid" while johndoe@homepc.local will be accepted.

I don't think it makes sense for gitea to validate emails at this point. AFAIK these emails serve two purposes:

  1. Send email notifications
  2. Associate the user with the emails in git histories

Git 2.33.0 considers johndoe@homepc a valid email and does not complain if commits are signed with it. When such commits are pushed to gitea, gitea then displays the author as johndoe with no way of associating the actual gitea user with this. Since a git host like gitea should fully support all repositories produced by git, this seems to me like a bug with respect to point 2.

If we allow "invalid" emails to be added to the profile, then occasionally this might break point 1. There is anyhow no way to guarantee that sending emails won't occasionally fail, so letting users enter "invalid" emails does not actually introduce any new corner cases. Users can already enter invalid emails if they really want, the validation just requires the email to be invalid while conforming to a regex, so no problem is being solved here while the user is inconvenienced. That said, if validation is seen as necessary, perhaps emails could be validated not when they are being added, but when notifications are enabled for them.

@zeripath
Copy link
Contributor

You should propose a PR to https://gitea.com/go-chi/binding:

To change this line https://gitea.com/go-chi/binding/src/branch/master/binding.go#L236:

	EmailPattern        = regexp.MustCompile("[\\w!#$%&'*+/=?^_`{|}~-]+(?:\\.[\\w!#$%&'*+/=?^_`{|}~-]+)*@(?:[\\w](?:[\\w-]*[\\w])?\\.)+[a-zA-Z0-9](?:[\\w-]*[\\w])?")

to:

	EmailPattern        = regexp.MustCompile("[\\w!#$%&'*+/=?^_`{|}~-]+(?:\\.[\\w!#$%&'*+/=?^_`{|}~-]+)*@(?:[\\w](?:[\\w-]*[\\w])?\\.)*[a-zA-Z0-9](?:[\\w-]*[\\w])?")

That would solve this issue.

@axifive
Copy link
Member

axifive commented Sep 14, 2021

@zeripath How about make EmailPattern changeable from admin settings page?
didn't notice that this is in go-chi

@metov
Copy link
Author

metov commented Sep 14, 2021

You should propose a PR to https://gitea.com/go-chi/binding:

Well, that would solve the specific issue I'm having. But it seems like it would get a bit tedious to amend that pattern every time someone discovers a new email pattern (and there is quite a few). Besides, I don't think git itself validates emails at all, so technically the email from git history can be any string.

@axifive Maybe not changing the pattern itself, but simply add a flag to admin settings about whether that pattern will be applied or not?

@metov
Copy link
Author

metov commented Sep 14, 2021

Also, if anyone else is having a similar problem, my workaround is:

  1. Add email with some placeholder TLD
  2. Navigate to the data directory containing gitea.db
  3. Open DB session: sqlite3 gitea.db
  4. See all emails: select email from email_address;
  5. Edit the one you want: update email_address set email = 'johndoe@homepc' where email = 'johndoe@homepc.local;

And then gitea will correctly associate the email with the commit.

@zeripath
Copy link
Contributor

@metov Our emails have to be mailable.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants