RFC: 注册权限的草案

[icyleaf]

描述 | Description

提供功能

1. 账户系统
2. 内置账户系统提供账户注册、登录、密码找回功能
3. 可配置第三方账户授权登录，包括但不仅限于后续开放的第三方有飞书、Google、Gitlab、LDAP、OpenID Connect 等。
4. 账户控制开关
5. 内置账户可开启或关闭注册功能
6. 第三方账户授权登录，可以独立控制每个的开启或关闭

功能逻辑

不限制注册

设置开启内置账户的注册为开启状态（默认为开启），配置每个第三方登录授权的设置并设置启用

限制内置账户注册

只需要设置内置账户的注册为关闭状态

限制第三方授权登录

单独控制具体第三方授权的设置为不启用

限制通用第三方登录

开启通用第三方授权的唯一优势是可以提供给第三方用户（客户）用于验收应用的安装和测试。

我觉得这是最不好控制的地方，对于自建的第三方服务来说还好陌生人没有账户权限，但如果开启了官方 Google、官方 Gitlab 授权登录，理论上无法控制拥有其账户的陌生人的登录操作，我的建议是不要开启这类通用服务的授权，转而使用自建服务或者他们提供 OpenID Connect 的功能，比如 Google OIDC。

TODO: 对于此类功能可以考虑添加一个新的逻辑：等待管理员批准，只有管理员批准之后才能登录否则只会处于待批准状态且无法正常登录

限制所有账户注册、登录（邀请模式）

在限制所有的账户授权后因为有默认管理员账户的存在，服务会变成邀请模式，只有管理员在管理面板的用户模块邀请未注册用户给其他人使用。

[Issues-translate-bot]

Bot translate issue to English automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

Title: RFC: Draft of registration rights

Description | Description

Provide functions

1. Account system
2. The built-in account system provides account registration, login, and password retrieval functions.
3. Third-party account authorization login can be configured, including but not limited to third parties that will be opened later, including Feishu, Google, Gitlab, LDAP, OpenID Connect, etc.
4. Account control switch
5. The built-in account can turn on or off the registration function
6. Authorized login with a third-party account, you can independently control the opening or closing of each

Functional logic

No registration restrictions

Set the registration of the built-in account to on (the default is on), configure the settings for each third-party login authorization and enable it.

Restrict built-in account registration

You only need to set the registration of the built-in account to closed state

Restrict third-party authorized login

Separately control the setting of specific third-party authorization to disable it

Restrict universal third-party login

The sole advantage of enabling universal third-party authorization is that it can provide third-party users (customers) with the means to install and test acceptance applications.

I think this is the hardest thing to control. For self-built third-party services, it’s good that strangers don’t have account permissions. But if you enable official Google and official Gitlab authorized logins, theoretically you can’t control strangers who have their accounts. For login operations, my suggestion is not to enable authorization for such general services, and instead use self-built services or the OpenID Connect functions they provide, such as Google OIDC.

TODO: For such features, consider adding a new logic: waiting for administrator approval, which allows login only after the administrator has granted approval; otherwise, it remains in a pending approval status and cannot log in normally.

Restrict all account registration and login (invitation mode)

After restricting all account authorizations, because of the existence of a default administrator account, the service will change to invitation mode. Only administrators can invite unregistered users to others in the user module of the management panel.