b_virtualserver_token_list not checking needed_member_add_power

[Elradon]

Don't know, weather this is a bug or not. But i would like to discus this.

If you want to add a token for a specific group, the needed_member_add_power and token_add permissions are checked, because otherwise you could make a token with higher permissions than you should have.
But if you want to list the tokens, just token_list is checked, not needed_member_add_power with consequence, that you can list and copy tokens for groups with higher permissions than you should have.

I think, that this is not how it should work. Think both, token_list and needed_member_add_power should be checked when listing tokens.

[Alcazar]

At first me thought, why should a group get "b_virtualserver_token_list" only?
Normally you give this in combination with "add" and/or "delete".
But me is getting your point.

You mean, if you have a group "Server Admin" and a group "Clan Admin" and both have permission to manage tokens.
So, now as a SA you create a token to make i. e. me a SA too. Until me uses this token, a "Clan Admin" can see it and use it for themselves right?

Interesting, could be nice idea to change this.

[Elradon]

Yes right. That is what I mean. Again: "Clan Admin"s can manage tokens (add, delete, list). I (as Server Admin) make a Server-Admin-Token for one Clan Admin - but every Clan Admin can see and use it...

[Jordi]

The token can only be used once.

[Elradon]

Yes, but there is a time between creation and using. Hard problem in the case of web-based token creation.

[Jordi]

Disable b_virtualserver_token_list for the Clan_Admin's.
They can create Token by Invite_Budy

[Elradon]

Its not my point to get a workaround for this. I realized, that this might be a bug which might corrupt the permission system. Don't you mean, that the list feature should check for the add_power of the guy who is listing the tokens?

[dante696]

The question for me is, does the client know the needed member add power, while he gets the list.
In my opinionon > No he does not know any add power.

"failed on i_group_member_add_power" comes up, after the you have tried to create that token, so the client tells the server to create it and compares the permission just in that moment.

[Alcazar]

That would make sense.
Maybe Elradon would be satisfied with a permission similar to "b_client_complain_delete_own" and "b_client_ban_delete_own"

[dante696]

The problem here is, that the ban list does use the flag "invoker". This can identify the user, who created that ban and sorts it for this value.
But the token only got the Group and target channel and description in it. The whole privilige key function needs an overhaul then.

I don't think, that this wll be done.

[Screech]

I like this suggestion. Would be useful. Right now on my servers I only allow SA to see list, even though Normal members can send invites with visitor group so they can get by the server password without knowing it.

@Dante: To me the original suggestion was that tokens be filtered from the list if the needed member add power of the group the token targets is greater than that of the user requesting/viewing the list. Assuming the select for the token list that is returned to the client runs at the server and the server knows the needed add values and the add power of the user, this should be updatable in the server code. This should be do able without the invoker info, though having a delete own is not that bad an idea. Yes, a delete own option would require a new field in the table of course and some extra code on related screens, not sure I would call that an overhaul.

Look at it more the hard part would be looking at the users member add power in the channels the channel group tokens are for. Not impossible, just a little more complex than I first thought.

[Elradon]

Yes! That's what I think how it should be. The server should check the needed_add_power and add_power of the client _before_ sending the token list.

[dante696]

I made a ticket for this, but it does not mean, that the developers will implement this feature!
Ticket ID TS-774

[Elradon]

Of cause, thank you very much!

[Elradon]

Something new about the ticket?