[Bug]: ENABLE_USER_SIGN_UP is ignored in the all-in-one docker image

[ricardopadilha]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

I deployed an instance of lowcoder using both of these instructions:

• https://docs.lowcoder.cloud/lowcoder-documentation/setup-and-run/self-hosting
• https://github.com/lowcoder-org/lowcoder/blob/main/deploy/docker/README.md

Even if I set ENABLE_USER_SIGN_UP environment variable as false, the "Sign Up" link is visible and functional. Anyone can just access my instance and create an account.

Expected Behavior

When ENABLE_USER_SIGN_UP is set to false, there should be no "Sign Up" link in the login page.

Steps to reproduce

1. Create an instance of the all-in-one docker version of lowcoder, making sure that ENABLE_USER_SIGN_UP is set to "false".
2. The "Sign Up" link is visible in the login page.

Environment

• Docker version 20.10.14, build a224086

Additional Information

No response

[FalkWolsky]

We fixed this with v2.1.3

[slfhstr]

We fixed this with v2.1.3

It's still an issue today using docker-compose and lowcoderorg/lowcoder-ce:latest
Quite serious vulnerability

NB : there is nothing in the app UI to indicate which version is running.
Not essential but very useful to have available somewhere (e.g. bottom of screen).

[FalkWolsky]

We researched both questions.

Generally it is like this: If we would suppress fully the ability to register a user, nobody would be able to login into Lowcoder. This makes naturally no sense. Therefore the Logic is like this:

Given that the COMMON_WORKSPACE_MODE is SAAS (people can create workspaces) We differentiate some situations:
ENABLE_USER_SIGN_UP = false -> First User ever -> Still able to register himself
ENABLE_USER_SIGN_UP = false -> Next Users -> Can register - but this will only make them standard users (members) of the already existing workspace.

They are then not treated as typical registered (when not used a invite link) like an admin and get an own workspace.
Based on the User-Groups and publishing of apps to these, you can then control, what this users will see.
If you publish only to selected "other" user-groups then "Members", their view will be empty and they can pretty much do nothing there.
Or you want to publish apps to such users - which you can by selecting them with the "share menu" before publishing.

[FalkWolsky]

The second question is "where to see the version". This is not truly big mentioned, agreed.
However, when you edit an app, then in the left bottom corner you have a small "help menu".
You find here Links to Documentation etc. But also the display of the current version.

[slfhstr]

Thank you for the explanation which makes sense, although maybe a non-standard approach.
This can be addressed in documentation, or maybe by an additional comment in the docker-compose.yaml file.
You have helpful comments there already, and an extra one for this would help.

The main problem is that the words ENABLE_USER_SIGNUP are not aligned with most users expectations of what that parameter would mean.
A more clear accurate parameter label would be ENABLE_ADMIN_SETUP.

Best solution would be change parameter label, but maybe this has implementation difficulties to flow through the code.
But adequate solution would be to document somewhere, at least in the docker-compose.yaml, what it actually does.

[FalkWolsky]

Absolutely agree! We have to take this to our documentation.
Also, a better cleanup of all names of ENV Vars is coming soon.

[ricardopadilha]

I appreciate the replies, but I believe that my original concern has not been addressed. As @timconsidine mentioned, I expected that the option ENABLE_USER_SIGNUP would allow me to disable the self-signup completely, and allow me to restrict signups only to invitation links. Is this behavior possible at all, and if so, how do I configure it?

[FalkWolsky]

Question... You set the environment Variable "ENABLE_USER_SIGNUP" to false and start your Docker.
We fully appreciate the ENABLE_USER_SIGNUP Setting and do not show the Sign Up Dialogue.
How the first user sign up and would be able to create any Invite Link?

Second Question. You run Lowcoder for multiple Teams in a Company and use the Workspace Mode (SAAS).
So many Workspaces could be built. Do you see still to set "ENABLE_USER_SIGNUP" - across all teams by force?
Or would you let Teams decide by themselves?

[slfhstr]

Question... You set the environment Variable "ENABLE_USER_SIGNUP" to false and start your Docker. We fully appreciate the ENABLE_USER_SIGNUP Setting and do not show the Sign Up Dialogue. How the first user sign up and would be able to create any Invite Link?

The approaches I have seen other repos take is :

• set first admin user and password in the docker-compose.yaml as an environment variable. This assumes some code to create an admin user in the database on container creation if it doesn't exist, but it's reasonably common approach. May be viable if you are re-working the environment variables.
• create a default user in database on container creation if one doesn't exist, with default values, e.g. admin : changemenow

Neither are great approaches but they happen a lot.

Another approach is to show signup if no users in database, but hide link from screen if ENABLE_USER_SIGNUP is false if users exist. The link can be guessed of course, which might be a vulnerability without some other coding.

They all have a coding overhead, and I don't know which is the least overhead.

Second question : it's a scenario to consider, but I don't have experience of best approach for this.

[FalkWolsky]

We think we to go with the second option.
For this we currently have 2 variables:
AUTH_EMAIL_ENABLE (this is currently ignored). If =false, we would show the eMail based Form exactly once - at the beginning for the very first admin user.

ENABLE_USER_SIGN_UP is currently active IF the COMMON_WORKSPACE_MODE=SAAS.
Then it works and no one can sign in.

At a point we agree with @ricardopadilha. Cause we do show the eMail based Form always (currently). We need to change this and hide it properly.

[FalkWolsky]

If you find it still not working, please re-open.

[lanedsmu]

As we're moving forward with implementing lowcoder, we're also finding this current behavior to be somewhat problematic.

In our enterprise, we never want users to be able to create a login for themselves, and we don't want to introduce the additional confusion that is created by the email login form. While I like the idea of the workspaces, I don't know that we really need it; @FalkWolsky, if we changed from saas mode, would that address some of this?

[FalkWolsky]

Yes. As soon as you have the Mode set to ENTERPRISE, workspaces will not appear.
However, the central Login Page still exist and it have to be - to ensure security.
However, we work on it to finally fix the behaviour. We introduced a SUPERUSER and with v2.4 we introduce SMTP settings for Password Reset flows.

[lanedsmu]

That makes sense. We'll be eager to hide the sign up and email login form fields when we can--either for specific workspaces or globally-- as we're finding they introduce confusion, rather than making things easier. If there were even an option to do so via CSS, we'd be pleased to go that route; that'd be something we could undo if needed, to re-enable that login path.

Related: if it were possible to add additional/different text to the Oauth button, that'd be very helpful as well: Keycloak isn't a platform our users are familiar with (even if they've used it unknowningly across the org), so being able to add a "click here to sign in with your network credentials" or similar guidance would be nice.