Different users with same e-mail causes error on create repositores and user creation from register

[joubertredrat]

• Gogs version (or commit ref): 0.9.97.0901
• Git version: 1.9.1
• Operating system: Ubuntu 14.04.5 LTS x64
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • SQLite
• Can you reproduce the bug at https://try.gogs.io:
  • Yes (https://try.gogs.io/user/activate?code=2016092109210001800019682194a3e5a3bfe65a90bcd11eb7a010eea972656472617432)
  • No
  • Not relevant
• Log gist: https://gist.github.com/joubertredrat/7792a5e54410795c8cca270f96a4efe2

Description

I identified 2 issues about different users with same e-mail, one on my environment and other on demo.

On mine Gogs instance I have my one user provided by SMTP authentication with e-mail my@email. Today I created one local user with same e-mail my@email. After this, both users can't create repositories, as is in gist above. Other users can create repositories without problems.

For see if I can reproduce same problem, I go to test on Gogs demo, I created user redrat1 without problems. Then, I created user redrat2 with same email from redrat1. I received email to activate account, but If I try to enable user redrat2, causes error 500.

Reference: gogs/gogs#3681

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/38896692-different-users-with-same-e-mail-causes-error-on-create-repositores-and-user-creation-from-register?utm_campaign=plugin&utm_content=tracker%2F47456670&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F47456670&utm_medium=issues&utm_source=github).

[strk]

I think forbidding multiple users with same email could be a good idea, in general.

[joubertredrat]

@strk If define email as UNIQUE in database and creates validation solves the problem

[lunny]

An unique maybe not a good idea since there are the same email. It will result in the gitea can not start.

[strk]

@lunny that's a migration/upgrade problem, yes, but if we think same-email should not be allowed, it would be useful to start preventing that for future accounts at least. Of course it's also important for code to be tolerant to unexpected database states.

[lunny]

If user already have same emails on gitea/gogs database, when he upgrade gitea to the new version, it will report a migration error and will not start the service. At this situation, user MUST change the user's email on the database manually. That's not our expected situation. So we have to resolve this before we add an unique tag on email field.

[bkcsoft]

If define email as UNIQUE in database and creates validation solves the problem

Like @lunny says, I've seen people (and bugs related to) use the same email for several accounts so a migration would be necessary.

Proposed migration flow:

No Collisions

• Currently at v0.9
• Upgrade to v1.1.0 (current milestone for this issue)
• Migration runs on start
• No duplicate emails found, Gogs starts as usual

Collisions

• Currently at v0.9
• Upgrade to v1.1.0 (current milestone for this issue)
• Migration runs on start
• Duplicate emails found, Gogs fails migration and throws an Error

PREFERED No Collisions

• Currently at v0.9
• Upgrade to v1.1.0 (current milestone for this issue)
• Migration runs on start
• No duplicate emails found, Gogs starts in Maintenance-mode, requiring Admins for login. Everything locked down except for settings.

Preferred way required Maintenance-mode (which hasn't been requested but would be nice )

[strk]

@bkcsoft you mean Duplicate emails found in the last bullet, right ?

I think we should go there incrementally, and the first step is preventing the registration of users with the same email as other users. From the original report in this ticket there is an attempt in code to prevent that (see how second user could not register with same email) but evidently not all code paths do check for that occurrence.

[bkcsoft]

@strk Correct. Changed the text now 😆

Indeed it should be done incrementally, could you have a look at that? 🙂

[richmahn]

Any work been done on this? We are needing to fix the problem as we have many people signing up through the API and they sometimes use the same email address, forgetting they are already in our system but with a different username.

[lunny]

We maybe fix this on 1.1. We would like to limit email should be uniqued. So that every user have to use different email. Maybe you can ask your guys to change their email address?

[strk]

Richard, are you able to provide a patch or pay someone to do so ?

[richmahn]

@strk: We work on Gogs as a company, but mainly our own customizations (click on my above issue I made for our developers to see our repo, which is tailored for content editing and content linking/scrubbing/etc. rather than coding), but do try to do what we can for upstream (gitea), so if we tackle the issue I made, we will do it for upstream.

@lunny: Every time the 500 error comes up, we finally (hopefully more quickly now than before) realize it is this bug and have to make a quick email change. I guess we need to somehow search for the email address from the app/api before signing someone up for now.

[simonszu]

I have noticed a similar behaviour which is somehow related to the duplicate-email-issue.
I have set up a fresh instance of gitea without migrating from gogits. I have created two users with different email addresses but changed one user's mail address to the other's after that.

The result is an Error 500 every time one of these users try to login. However, the session starts up fine, and if you manually navigate to the logged in user's dashboard, it seems to work - until you go and view the commit history of a repo or single file and try to view an older commit. There you get an Error 500 as well which is not workaroundable.

So i think a unique flag for email addresses and enforcing it at registration or in the user control panel would be the best solution.

[lunny]

@simonszu which version have you installed?

[simonszu]

@lunny I am a bit surprised that my installation does not report any version number, but a commit hash. It is Version: 6aacf4d. I installed it around Febrary 6th, 2017.

[lunny]

Yes. That's v1.0.1. I will fix this issue these days.