[Feature request] Account confirmation

[hasufell]

Account confirmation would be very helpful for controlling the amount of users on your server, especially when you are only interested in PRs and are not hosting for other people basically.

The user could also have an input field explaining why he wants access.

[hasufell]

Yesterday I enabled registration and instantly got a spam account, which was known by various forums it seems. REGISTER_EMAIL_CONFIRM was true and MAX_CREATION_LIMIT to 0 and even ENABLE_CAPTCHA was true, but this still doesn't ensure that your database is not flooded with spam accounts or someone attempts to DoS your gitea instance by forking and pushing GBs of data into the fork (afaiu forks are always allowed, even with MAX_CREATION_LIMIT = 0).

This makes it clear that this feature is important.

[mwaeckerlin]

I support this request, otherwise, gitea is completely unusable!

I created a gitea instance in March 2018. Now, in October 2018, I have 3635 registered SPAM-users! Even though there is ENABLE_CAPTCHA switched on.

There is a bug: When I enable REGISTER_EMAIL_CONFIRM, first of all the mail is not sent, probably due to missing TLS support in my local postfix, but then, the new user can login even without email confirmation!

Other question: How can I simply remove all spammers? There should be an option such as: «remove users with no contributions».

[adelowo]

How would this work ? The account is created but would be restricted from any user type action until approved by an admin. Makes sense to me.

Ping @lafriks @techknowlogick

[Pofilo]

Or the account is created but deleted if the mail of confirmation is not used within the 48 hours. What do you think about that ?

[adelowo]

Or the account is created but deleted if the mail
of confirmation is not used within the 48 hours.
What do you think about that ?

This makes sense...

We could add a gate subCmd which can then be ran as
a cronjob. I don't think something like this should run
via gitea web

[techknowlogick]

Instead of a Cron job (as that would require setup by the user) perhaps a similar way of how repo mirroring is done, then it's built into the binary.

[mwaeckerlin]

I suggest a combination:

1. The account is not activated before E-Mail-confirmation
2. Non-confirmed accounts are deleted after 48h

[mwaeckerlin]

BTW, what I see now:

• when I correctly setup mail (including TLS), then it works as intended
• when mail does not work, new users are immediately activated

I consider this as a bug.

BTW: It is good to enable TLS if SMTP is sent over internet. But I have an SMTP server connected to gitiea within a completely isolated network in docker swarm, so TLS makes no sense. I suggest to allow non-TLS SMTP connections too for this kind of use case.

[lafriks]

I don't think TLS should have affect on user activation

[mwaeckerlin]

I don't think TLS should have affect on user activation

Currently, gitea enforces TLS — which is good, if you go through internet, but not necessary, if the SMTP server is in the same VPN, as in my case.

The affect to the activation is indirect: If the mail configuration is not correct, activation is simply ignored (instead of rejected).

[techknowlogick]

TLS for SMTP is only enforced on port 465, please also refer to the IS_TLS setting that you can toggle as well for other ports

[mwaeckerlin]

Nope, my SMTP server is conform to the standard and therefore runs on port 25.

[adelowo]

True though 25 is the official port for SMTP's TLS, 465 was meant for something called SMTPS but they figured out we could use TLS over SMTP, so it was revoked. But 465 already signified encryption, so I think a lot of people kept on using it.

@techknowlogick I think we should enforce TLS for both 465 and 25 though

I'd even go as far as saying 465 shouldn't be used as IANA has assigned the port to something else https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt