Suggestion: Allow first user to register without invite link

[namatoj]

I was exploring ways of lowering the bar of getting started with a new cerca setup.

What do you think about allowing the first user in an instance to register without an invite link? (And also making this user admin)

Or maybe what I am really after is a "one time use" invite code that gives you admin access. That could be created when the database is created.

To be frank I am not entirely convinced myself that it is a good idea, but I felt the need to write it down to sort my thoughts about it.

[cblgh]

Was speaking with namatoj during an event, and ideated a new cli command for the cerca binary that can be used to generate an invite link e.g. cerca invite. If that command can also be made to accept whether the invite should create an admin user or not then we're good for solving the above issue :)

If pursuing: invite codes making people admins would need to be added in the invite code, probably as a new routine

[namatoj]

I started dabbling with this functionality in a fork (https://github.com/namatoj/cerca/tree/create-invite-from-cli if interested)

I am likely going to do it in two steps:

• Step 1: Make a cli command to create invitations
• Step 2: Make it possible to create admin-invitations.

Regarding step 1, in the branch in the fork mentioned above, it almost works. To make it work I needed to manually made the "SystemUser" admin since the db.CreateInvites()-function does an admin check before an invite is created.

In order to solve that I see two (so far) alternative ways forward:

1. Assume the SystemUser should be admin and make sure it is created as such and add a migration to make sure an already created SystemUser gets the admin privilege.
2. Remove the admin check from db.CreateInvites since an admin check is already done in the route (see https://github.com/cblgh/cerca/blob/main/server/moderation.go#L465).

I think alternative 2 is nicer and more straight forward, it also makes "create invite" more similar to the approach for resetting passwords. When resetting a password for a user, it is checked in the route if the user trying to do it is admin. However, the password reset function db.ResetPassword does not do an admin check.

I should go with alternative 2 right? :)

[cblgh]

@namatoj sorry for the delay! in cases like these, e.g. subtly altering the functionality of CreateInvite, i want to verify whether it was that way intentionally or because of a happenstance.

after looking a bit, i think it would be better to treat SystemUser as a special case but not elevate it to admin? so something like:

in database/moderation.go:CreateInvites

	if !isAdmin {
                // the only user allowed to create invites w/o elevated role is the system user (CERCA_CMD)
                if adminId != db.GetSystemUserID() {
		           return fmt.Errorf("userid %d was not an admin, they can't create an invite", adminid)
                }
	}

that keeps it the way it is, limits any potential malicious attacks in the future by keeping CreateInvites scoped to admins, and also avoids giving CERCA_CMD any admin role.

then for the command itself check out what the "cerca reset" command is doing in terms of loggin the operation.

https://github.com/cblgh/cerca/blob/main/cmd/cerca/reset.go#L41-L60

but use with something like

modlogErr := h.db.AddModerationLog(db.GetSystemUserID(), -1, constants.MODLOG_CREATE_INVITE_BATCH)