-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add the user to automatic rights groups #516
base: master
Are you sure you want to change the base?
Conversation
add the team's user type and also a generic all user type This allows you to give permissions to run certain, usually restricted commands to anyone or to a certain team
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice to document the behaviour of this - at least a comment in the example config.toml and details in the sphinx docs.
team_usertype = None | ||
|
||
if team is self.protocol.team_1: | ||
team_usertype = "team_1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps we could use team1
and team2
to be consistent with the toml config sections?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good point. Kind of unfortunate that our config and code differ now.
elif team.spectator: | ||
team_usertype = "spectator" | ||
|
||
if team_usertype: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If no team_usertype
, shouldn't all the special usertypes still be removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's true. team_usertype will never be None in the forseeable future, so the if
is pretty pointless anyway.
@@ -88,8 +91,6 @@ def on_login(self, name: str) -> None: | |||
self.protocol.irc_say('* %s (IP %s, ID %s) entered the game!' % | |||
(self.name, self.address[0], self.player_id)) | |||
if self.user_types is None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change to if not self.user_types:
since it might be an empty set rather than None.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, you're right, we have a problem here. But it's a different one. on_join
is called multiple times for the lifetime of a connection, once per match. We probably don't want to login the users as admin every time when a new match starts. But we need the user to be joined to be able to execute on_user_login
as it might send chat messages.
Easiest thing is probably to defer initialization of the sets to on_join
after all.
Something else to consider: server config shouldn't allow giving passwords for built-in roles such as relevant code: piqueserver/piqueserver/core_commands/social.py Lines 4 to 26 in b673305
|
Why not? I don't see any harm in this technically being possible. It should work fine, but it'd be pretty pointless... I don't think we need to protect our users from being able to do something pointless? |
I guess. I was thinking just a check that rejected logging in with a message about it being an automatic/dynamic role. |
add the team's user type and also a generic all user type
This allows you to give permissions to run certain, usually restricted
commands to anyone or to a certain team
closes #475