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

REGISTER_MANUAL_CONFIRM does not require manual change to Activated as described #17263

Closed
spacehobo opened this issue Oct 7, 2021 · 3 comments · Fixed by #19119
Closed

REGISTER_MANUAL_CONFIRM does not require manual change to Activated as described #17263

spacehobo opened this issue Oct 7, 2021 · 3 comments · Fixed by #19119
Labels
Milestone

Comments

@spacehobo
Copy link

Gitea Version

1.15.3

Git Version

2.17.1

Operating System

Ubuntu 20.04.3 LTS, but gitea runs under snap core 16-2.51.7 2021-09-30

How are you running Gitea?

I am using the snap package of gitea, version latest/stable: v1.15.3 2021-09-22 (5629) 59MB -

Database

SQLite

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Description

I have reported this on the discourse as well.

My use case is a gitea installation that is well cared-for during time when I can devote attention to personal projects, but which may stand neglected for part of the year. My goal is to configure it so that strangers cannot surprise me by registering on it and uploading content over which I have no control. To that end, I would like to be able to manually approve new signups after verifying that they are indeed my friends and project collaborators.

To this end, I am using REGISTER_MANUAL_CONFIRM = true in the [service] section of my configuration, which per the docs requires that I also set REGISTER_EMAIL_CONFIRM = false. I am hard re-starting gitea after updating the app.ini, and testing creation of a new user.

Each time I create a user, it sends me a confirmation via e-mail. Clicking that e-mail confirmation link results in a fully activated user, which I confirm by visiting the admin panel in another browser (per the screenshots). Per the discord configuration channel, I was advised to file this as a bug, as it seemed to norwin#8935 that the behaviour I am seeing is clearly at odds with the documentation for REGISTER_MANUAL_CONFIRM.

What follows is the complete and entire [service] section of my app.ini, in case some other option turns out to be conflicting with REGISTER_MANUAL_CONFIRM:

[service]
REGISTER_EMAIL_CONFIRM            = false
REGISTER_MANUAL_CONFIRM           = true
ENABLE_NOTIFY_MAIL                = false
DISABLE_REGISTRATION              = false
ALLOW_ONLY_EXTERNAL_REGISTRATION  = false
ENABLE_CAPTCHA                    = false
REQUIRE_SIGNIN_VIEW               = false
DEFAULT_KEEP_EMAIL_PRIVATE        = true
DEFAULT_ALLOW_CREATE_ORGANIZATION = true
DEFAULT_ENABLE_TIMETRACKING       = true
NO_REPLY_ADDRESS                  = noreply.example.org

I am unable to reproduce on try.gitea.io because this is a problem with server configuration. If I am mistaken and there are facilities on that site to perform these sorts of experiments, I am happy to give that a go.

Screenshots

Screenshot from 2021-10-07 21-07-56
Screenshot from 2021-10-07 21-08-03
Screenshot from 2021-10-07 21-08-21
Screenshot from 2021-10-07 21-09-06
Screenshot from 2021-10-07 21-09-17
Screenshot from 2021-10-07 21-09-38

@noerw
Copy link
Member

noerw commented Oct 7, 2021

It looks like we don't take the REGISTER_EMAIL_CONFIRM into account at all when sending the activation mail here 🤔

gitea/routers/web/user/auth.go

Lines 1331 to 1333 in 91e21d4

// Send confirmation email
if !u.IsActive && u.ID > 1 {
mailer.SendActivateAccountMail(ctx.Locale, u)

Generally it would make sense to decouple REGISTER_MANUAL_CONFIRM from the User.IsActive flag. Conflating email confirmation with manual review seems quite odd.

@poka-IT
Copy link

poka-IT commented Feb 12, 2022

Exact same problem here, REGISTER_MANUAL_CONFIRM doesn't do anything.
The only way to block spams is to disable registration completely...

Any news about it ?

@skobkin
Copy link

skobkin commented Mar 17, 2022

Same on my instance.

Gitea Version: 1.16.4, set up using Docker image gitea/gitea:latest (423b8c425d76)

[service]
DISABLE_REGISTRATION              = false
REGISTER_EMAIL_CONFIRM            = false
REGISTER_MANUAL_CONFIRM           = true
ENABLE_NOTIFY_MAIL                = true
ALLOW_ONLY_EXTERNAL_REGISTRATION  = false
// ...

But still when trying to register, new user gets confirmation mail and after clicking the link their account is activated without any action from the administrator.

zeripath added a commit to zeripath/gitea that referenced this issue Mar 17, 2022
If the mailer is configured then even if Manual confirm is set an activation email
is still being sent because `handleUserCreated` is not checking for this case.

Fix go-gitea#17263

Signed-off-by: Andrew Thornton <art27@cantab.net>
@lunny lunny added this to the 1.16.5 milestone Mar 18, 2022
lunny added a commit that referenced this issue Mar 18, 2022
If the mailer is configured then even if Manual confirm is set an activation email
is still being sent because `handleUserCreated` is not checking for this case.

Fix #17263

Signed-off-by: Andrew Thornton <art27@cantab.net>

Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
zeripath added a commit to zeripath/gitea that referenced this issue Mar 18, 2022
Backport go-gitea#19119

If the mailer is configured then even if Manual confirm is set an activation email
is still being sent because `handleUserCreated` is not checking for this case.

Fix go-gitea#17263

Signed-off-by: Andrew Thornton <art27@cantab.net>

Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
zeripath added a commit that referenced this issue Mar 19, 2022
Backport #19119

If the mailer is configured then even if Manual confirm is set an activation email
is still being sent because `handleUserCreated` is not checking for this case.

Fix #17263

Signed-off-by: Andrew Thornton <art27@cantab.net>
Chianina pushed a commit to Chianina/gitea that referenced this issue Mar 28, 2022
If the mailer is configured then even if Manual confirm is set an activation email
is still being sent because `handleUserCreated` is not checking for this case.

Fix go-gitea#17263

Signed-off-by: Andrew Thornton <art27@cantab.net>

Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
@go-gitea go-gitea locked and limited conversation to collaborators Apr 28, 2022
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