[installer]: add validation rules to blockNewUsers in config block #13126
Conversation
mrsimonemms
force-pushed
the
mrsimonemms/add-validation-check-13114
branch
from
b63291c to
d8c8a7c
Compare
github-actions
bot
added
the
team: delivery
| @@ -55,6 +55,8 @@ func Validate(version ConfigVersion, cfg interface{}) (r *ValidationResult, err | |||
| res.Fatal = append(res.Fatal, fmt.Sprintf("Field '%s' is %s '%s'", v.Namespace(), tag, v.Param())) | |||
| case "startswith": | |||
| res.Fatal = append(res.Fatal, fmt.Sprintf("Field '%s' must start with '%s'", v.Namespace(), v.Param())) | |||
| case "block_new_users_passlist": | |||
| res.Fatal = append(res.Fatal, fmt.Sprintf("Field '%s' failed. If 'Enabled = true', there must be at least one fully-qualified domain name in the passlist", v.Namespace())) | |||
There was a problem hiding this comment.
Maybe Warning is better, for the existing self-hosted
SH (for my case) I only want people I invited to join, admin's may don't want accounts to be created automatically to save seats
There was a problem hiding this comment.
No, I think fatal is correct. If you don't have any domains in the passlist then you end up in a broken state where the initial admin user gets blocked and you've basically bricked the installation. The only way I've found to resolve this is by deleting the database (I guess it's possible to do by deleting specific DB records, but I don't know those)
There was a problem hiding this comment.
It's good for new SH installation. But for existing SH, they need to LeanMore and change their config.yaml
And it blocks my case -- an empty passlist.
(My case also not allow me to use the same domain of email, so it's useless for my case like small company?)
There was a problem hiding this comment.
We can fix it by making first account available?
There was a problem hiding this comment.
Yeah, if there's an exception made to never block the first account then that would remove this problem completely.
I'd propose keeping the test as a fatal error, but it would remove the requirement for option 2 in the original test scenarios:
If
blockNewUsers.enabledis set totrueandblockNewUser.passlistis set to[]- this should fail
Description
If a user selects the option to limit their user registrations (which they should if on public internet), it is possible to get their Gitpod instance into a weird state where the initial admin user is blocked if they had configured no items in the passlist.
This adds a validation check to ensure that is not possible.
Related Issue(s)
Fixes #13114
How to test
Four scenarios to check:
blockNewUsers.enabledis set tofalseandblockNewUsers.passlistis set to[]- this should passblockNewUsers.enabledis set totrueandblockNewUser.passlistis set to[]- this should failblockNewUsers.enabledis set totrueandblockNewUser.passlistis set to["somedomain"]- this should failblockNewUsers.enabledis set totrueandblockNewUser.passlistis set to["somedomain.com"]- this should passUse
go run . validate config -c /path/to/config.yamlto execute without building the binaryRelease Notes
Documentation
Werft options:
Valid options are
all,workspace,webapp,ide