-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Comments
It looks like we don't take the gitea/routers/web/user/auth.go Lines 1331 to 1333 in 91e21d4
Generally it would make sense to decouple |
Exact same problem here, REGISTER_MANUAL_CONFIRM doesn't do anything. Any news about it ? |
Same on my instance.
[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. |
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>
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>
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>
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>
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 setREGISTER_EMAIL_CONFIRM = false
. I am hard re-starting gitea after updating theapp.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 tonorwin#8935
that the behaviour I am seeing is clearly at odds with the documentation forREGISTER_MANUAL_CONFIRM
.What follows is the complete and entire
[service]
section of myapp.ini
, in case some other option turns out to be conflicting withREGISTER_MANUAL_CONFIRM
: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
The text was updated successfully, but these errors were encountered: