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

Registration fails when SHOW_REGISTRATION_BUTTON = false #5183

Closed
2 of 7 tasks
lpoujol opened this issue Oct 25, 2018 · 4 comments · Fixed by #8237
Closed
2 of 7 tasks

Registration fails when SHOW_REGISTRATION_BUTTON = false #5183

lpoujol opened this issue Oct 25, 2018 · 4 comments · Fixed by #8237
Labels
issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented type/bug
Milestone

Comments

@lpoujol
Copy link

lpoujol commented Oct 25, 2018

Description

Hi,
I've been trying gitea with some coworkers. For our tests, I've decided to go with registration enabled but with the registration button hidden. So our config looked like :

[service]
DISABLE_REGISTRATION = false
SHOW_REGISTRATION_BUTTON = false
REGISTER_EMAIL_CONFIRM = true
ENABLE_CAPTCHA = true

As expected, the registration button is hidden, but the registration page is visible. Then after filling the form. Validating it leads to a 403 page with empty content. No user is created.

Expected behavior : Registration works, and a new account is created.

Also, when SHOW_REGISTRATION_BUTTON is set to true, registration do work as expected.

Screenshots

gitea_403

@lunny
Copy link
Member

lunny commented Oct 25, 2018

It seems no error on log files.

@r-52
Copy link

r-52 commented Nov 30, 2018

You can reproduce this behavior with the mentioned settings. You can reach the regular SignUp page because there's nothing that checks the settings entry SHOW_REGISTRATION_BUTTON.

func SignUp(ctx *context.Context) {

If you hit the send button/trigger the form-post, the action checks if SHOW_REGISTRATION_BUTTON is true or returns the 403.

gitea/routers/user/auth.go

Lines 926 to 929 in c8a9384

if !setting.Service.ShowRegistrationButton {
ctx.Error(403)
return
}

I believe there are two ways to change this:

  • already check SHOW_REGISTRATION_BUTTON in the get action to return a 403 or redirect to login.
  • keep the current behavior, but remove the check in the post action to keep a semi-hidden signup page, that is not reachable from the navbar

what do you think? Is it worth a pr?

@lunny
Copy link
Member

lunny commented Nov 30, 2018

@romankl PR is welcome.

r-52 added a commit to r-52/gitea that referenced this issue Nov 30, 2018
Previously you could hide the sign up page with the following
configs:

```
[service]
SHOW_REGISTRATION_BUTTON          = false
```

This would remove the sign up button from the navbar, but the user
could still access the page with a direct link. During the http post
action, the go action checked if the key `SHOW_REGISTRATION_BUTTON` was
set to true. If not, the user received a 403.

You can use this scenario for a semi-hidden sign up page that is only
accessible through a direct link.

I've changed the check in this PR to check if the sign up is allowed
or not. The user can access the sign up page (if it's enabled) and
sign up even if the value of `SHOW_REGISTRATION_BUTTON` is `false`, the
user can sign up.

Another solution could be:
- unify `SHOW_REGISTRATION_BUTTON ` with `DISABLE_REGISTRATION ` to
only show the registration page if it's enabled, but that would dis-
allow the mentioned scenario

fixes: go-gitea#5183
Signed-off-by: Roman <romaaan.git@gmail.com>
@lafriks lafriks added this to the 1.6.1 milestone Nov 30, 2018
@techknowlogick techknowlogick modified the milestones: 1.6.1, 1.6.2 Dec 9, 2018
@techknowlogick techknowlogick modified the milestones: 1.6.2, 1.6.3 Dec 19, 2018
@lafriks lafriks modified the milestones: 1.6.3, 1.7.0 Jan 4, 2019
@techknowlogick techknowlogick modified the milestones: 1.7.0, 1.8.0 Jan 15, 2019
@techknowlogick techknowlogick modified the milestones: 1.8.0, 1.9.0 Mar 8, 2019
@stale
Copy link

stale bot commented May 7, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale stale bot added the issue/stale label May 7, 2019
@lunny lunny added the issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented label May 8, 2019
@stale stale bot removed the issue/stale label May 8, 2019
@techknowlogick techknowlogick modified the milestones: 1.9.0, 1.10.0 Jun 17, 2019
@lunny lunny modified the milestones: 1.10.0, 1.9.4 Sep 19, 2019
@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented type/bug
Projects
None yet
5 participants