You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
This is the promised follow-up to #7052 about how to creating and deleting aliases could be more consistent. In general these are implemented via the create_association and delete_association methods of DirectoryHandler.
The checks done for each of these (copied from #7052 and clarified a bit) below. They're a bit confusing (and maybe make more sense as the flow-charts I wrote out), but the overall checks aren't too complicated.
Creation
Check if the length is valid.
If require_membership_for_aliases is true in the config, the creator must be in the room or be a server admin.
The spam checker's user_may_create_room_alias method is queried.
The alias_creation_rules are checked from the config.
Services are checked to see whether they have an "exclusive lock" on an alias.
Deletion
Ensure that the user is the room creator, if one exists.
Ensure that the alias points to a room ID.
The user must be one of the following:
A server admin.
In the room and have sufficient power level to delete an alias (>= moderator).
Services are checked to see whether the have an "exclusive lock" on an alias.
Potential improvements
There aren't too many changes I came up with, but see ideas below:
Check require_room_membership_for_aliases during alias deletion.
Ensure that a user has the proper power level during creation (but that probably only makes sense for the canonical alias, which already happens).
There's a chance that some of the code could be re-used by combining some of the checks, but probably not. Frankly this might just be good enough the way it is.
The text was updated successfully, but these errors were encountered:
This is the promised follow-up to #7052 about how to creating and deleting aliases could be more consistent. In general these are implemented via the
create_association
anddelete_association
methods ofDirectoryHandler
.The checks done for each of these (copied from #7052 and clarified a bit) below. They're a bit confusing (and maybe make more sense as the flow-charts I wrote out), but the overall checks aren't too complicated.
Creation
require_membership_for_aliases
is true in the config, the creator must be in the room or be a server admin.user_may_create_room_alias
method is queried.alias_creation_rules
are checked from the config.Deletion
Potential improvements
There aren't too many changes I came up with, but see ideas below:
require_room_membership_for_aliases
during alias deletion.There's a chance that some of the code could be re-used by combining some of the checks, but probably not. Frankly this might just be good enough the way it is.
The text was updated successfully, but these errors were encountered: