github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-12 02:24:21 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

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

New Issue
Closed
opened 2025-11-02 07:42:30 -06:00 by GiteaMirror · 3 comments
GiteaMirror commented 2025-11-02 07:42:30 -06:00
Owner
Copy Link

Originally created by @spacehobo on GitHub (Oct 7, 2021).

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

Originally created by @spacehobo on GitHub (Oct 7, 2021). ### 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](https://discourse.gitea.io/t/moderation-of-new-users/3876) 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`: ```ini [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](https://user-images.githubusercontent.com/8015250/136455287-26665061-7c0c-4974-9ba9-6de0763f1cb2.png) ![Screenshot from 2021-10-07 21-08-03](https://user-images.githubusercontent.com/8015250/136455285-9dbfb5d8-25d4-4c29-9873-6a0385886f32.png) ![Screenshot from 2021-10-07 21-08-21](https://user-images.githubusercontent.com/8015250/136455284-e604e916-df8d-4398-88aa-2b6a1b3b29ca.png) ![Screenshot from 2021-10-07 21-09-06](https://user-images.githubusercontent.com/8015250/136455283-c772a503-ed4f-4ae4-b564-ab05889a92da.png) ![Screenshot from 2021-10-07 21-09-17](https://user-images.githubusercontent.com/8015250/136455281-68510011-fa25-4dda-a9a8-6d4076f0ccff.png) ![Screenshot from 2021-10-07 21-09-38](https://user-images.githubusercontent.com/8015250/136455278-b19b7555-6f9f-435f-83e8-410281ecedfa.png)
GiteaMirror added the type/bug label 2025-11-02 07:42:30 -06:00
GiteaMirror commented 2025-11-02 07:42:31 -06:00
Author
Owner
Copy Link

@noerw commented on GitHub (Oct 7, 2021):

It looks like we don't take the REGISTER_EMAIL_CONFIRM into account at all when sending the activation mail here 🤔
91e21d4fca/routers/web/user/auth.go (L1331-L1333)

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

@noerw commented on GitHub (Oct 7, 2021): It looks like we don't take the `REGISTER_EMAIL_CONFIRM` into account at all when sending the activation mail here 🤔 https://github.com/go-gitea/gitea/blob/91e21d4fca8b867614d08537e92bc6c8fc7b0444/routers/web/user/auth.go#L1331-L1333 Generally it would make sense to decouple `REGISTER_MANUAL_CONFIRM` from the `User.IsActive` flag. Conflating email confirmation with manual review seems quite odd.
GiteaMirror commented 2025-11-02 07:42:31 -06:00
Author
Owner
Copy Link

@poka-IT commented on GitHub (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 ?

@poka-IT commented on GitHub (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 ?
GiteaMirror commented 2025-11-02 07:42:31 -06:00
Author
Owner
Copy Link

@skobkin commented on GitHub (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.

@skobkin commented on GitHub (Mar 17, 2022): Same on my instance. `Gitea Version: 1.16.4`, set up using Docker image `gitea/gitea:latest` (`423b8c425d76`) ```ini [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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label type/bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#7951
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?