Typical flow with verificationEnabled setting set to true and all validation steps passing:
As before, a user joins a guild, therefore becoming a GuildMember (member)
The member is assigned the "_unverified_user" role
If the role doesn't already exist, it will be created by delet3 before being assigned to the member
If a channel with the name given in the verificationChannel setting (default: #verify-me) cannot be found, one will be created
This channel will have permissionOverwrites to deny @everyone from viewing this channel and allow unverified users, admins, mods and delet3 to view and use the channel
The member's ID and the current timestamp are stored in an object; this object is pushed to the verificationQueue.users array in the "guilds" MongoDB collection (see addToVerifQueue() and the Guild schema)
The member can then use the /verify command to verify themselves
To pass verification, the member must click the "Verify" button
Upon doing so, their "_unverified_user" role will be replaced with a "_verified" role
If this role doesn't already exist, it will be created by delet3 before being applied
Having this role should grant the user access to public channels in the guild
As the user no longer has the unverified role, they will no longer be able to see the verificationChannel
The object containing the member's ID is then removed from the verificationQueue.users array (i.e., the member has now been removed from the verificationQueue)
To ensure this system works as expected, it is recommended that the @everyone role (global permissions) does not have permission to view any channels, by default.
New settings
This system introduces the verificationEnabled and verificationChannel settings. The former determines whether the verification system is switched on/off; the latter determines the channel in which the /verify command can be used.
Database & API changes
The aforementioned new settings have been added to the Guild schema and are accessible via the /guilds route, inside the settings object
The verificationQueue has also been added to the Guild schema and /guilds route, but is not inside settings; it is in the outer scope instead.
Future
In the future, this system will likely be made more robust and advanced, by adding features such as a requirement to complete a captcha in order to pass verification.
Currently, verification info and error notifications are sent to the modLogChannel. In the future, a separate verificationLogChannel setting may be implemented, to ensure separation of concerns and to prevent the mod log doesn't get too cluttered.
This system also ties into another proposed security feature; an anti-raid system (#37), which may be implemented in a future release.
This PR:
How does it work?
Typical flow with verificationEnabled setting set to true and all validation steps passing:
permissionOverwritesto deny@everyonefrom viewing this channel and allow unverified users, admins, mods and delet3 to view and use the channelverificationQueue.usersarray in the "guilds" MongoDB collection (seeaddToVerifQueue()and theGuildschema)VIEW_CHANNELandSEND_MESSAGES(see interactions/commands/security/verify.js#L5 for the full list of permissions)To ensure this system works as expected, it is recommended that the
@everyonerole (global permissions) does not have permission to view any channels, by default.New settings
This system introduces the verificationEnabled and verificationChannel settings. The former determines whether the verification system is switched on/off; the latter determines the channel in which the /verify command can be used.
Database & API changes
settingsobjectsettings; it is in the outer scope instead.Future
In the future, this system will likely be made more robust and advanced, by adding features such as a requirement to complete a captcha in order to pass verification.
Currently, verification info and error notifications are sent to the modLogChannel. In the future, a separate verificationLogChannel setting may be implemented, to ensure separation of concerns and to prevent the mod log doesn't get too cluttered.
This system also ties into another proposed security feature; an anti-raid system (#37), which may be implemented in a future release.