Add admin room command to create registration tokens with attributes like expiry, username-bound, etc #166

New issue

Closed

opened 2024-02-19 04:42:42 +00:00 by girlbossceo · 2 comments

girlbossceo commented

2024-02-19 04:42:42 +00:00

(Migrated from github.com)

The expiry of the token will be checked at registration time, not using a timer or something. Could maybe consider a "maintenance" service to periodically check all the tokens' expiry and remove them with a message in the admin room that a token has expired and was removed, and check/clean them when a user interacts with token admin commands like listing all of them.

Registrations via created token can be logged in admin room. Can check this with a global service at registration-time.

For compatibility, the existing registration_token config option will be retained and untouched. That can serve as a "global" never-expiring registration token. The startup checks will need to be adjusted to forbid startup if registration is allowed without a "global" token set, or if there are no registration tokens in the database. An admin would need to set an "initial" token in the config, or disable registration and use the admin room to create at least one and re-enable registration later.

Thinking this can be implemented with a database kv table. Admin command to create a token with either an arbitrary specified token, or a randomly generated one. With arguments to set attributes on the token like a UNIX epoch timestamp in the future for expiry and for terms like `+7d` for 7 days which will convert to an epoch for the database (and "none" for no expiry), and for other attributes like the token being bound to a specific username only, have a set number of uses, auto join certain rooms with certain tokens, etc. The expiry of the token will be checked at registration time, not using a timer or something. Could maybe consider a "maintenance" service to periodically check all the tokens' expiry and remove them with a message in the admin room that a token has expired and was removed, and check/clean them when a user interacts with token admin commands like listing all of them. Registrations via created token can be logged in admin room. Can check this with a global service at registration-time. For compatibility, the existing `registration_token` config option will be retained and untouched. That can serve as a "global" never-expiring registration token. The startup checks will need to be adjusted to forbid startup if registration is allowed without a "global" token set, or if there are no registration tokens in the database. An admin would need to set an "initial" token in the config, or disable registration and use the admin room to create at least one and re-enable registration later.

👍 2 ❤️ 1

grinapo commented

2024-07-24 15:49:35 +00:00

(Migrated from github.com)

Logged registration line should contain the token and the username at minimum, so external token metadata could be assiciated with the user in case someone needs that.

Maybe useful to have the possibility to only record an admin provided token instead of generating, so it could be generated externally and only recorded in the admin room.

Logged registration line should contain the **token** and the **username** at minimum, so external token metadata could be assiciated with the user in case someone needs that. Maybe useful to have the possibility to only _record_ an admin provided token instead of generating, so it could be generated externally and only recorded in the admin room.