Temporal server keys

[Erkunder]

I suggest to add an option to generate temporal passwords or keys for a password protected server, similar to the "buddy invite".

Playing World of Warcraft, I've encountered a situation like this several times: You want to set up a larger group with your guild members and some random players. While you can "buddy invite" individual random players, this becomes impractical the more random players there are. Instead of having to give away your server password, it would be nice to be able to generate a temporal key wich is valid for more than one user but only a certain -- maybe arbitrary -- amount of time after issuing it. This way, improper circulation of the server password would be reduced and you wouldn't have to change it that often.

[Screech]

Well, just could have all your normal users have the ignore server password on join. Then set the password that you want to share, share it with those "temp" users. and when you want, change it again, "temp" users loose access and normal users don't even notice or need the new password.

I still use the invite buddy for a 1 to 1 invite system with the ignore password on that temp group.

Options aside, I too think it would be nice to be able create a permission key that is multi use with an expire time (like bans) where 0 seconds is a permanent permission key, but if deleted it is gone. Maybe add a max use option when making a permission key, 0 being unlimited.

[Erkunder]

Well, just could have all your normal users have the ignore server password on join. Then set the password that you want to share, share it with those "temp" users. and when you want, change it again, "temp" users loose access and normal users don't even notice or need the new password.

This would be a great option for small guilds with low fluctuation. Unfortunately, ours is neither small nor stable, so shifting every permanently authorised user to a group that ignores passwords wouldn't be substantial progress.

Options aside, I too think it would be nice to be able create a permission key that is multi use with an expire time (like bans) where 0 seconds is a permanent permission key, but if deleted it is gone. Maybe add a max use option when making a permission key, 0 being unlimited.

I completely agree with that.

[Screech]

Options aside, I too think it would be nice to be able create a permission key that is multi use with an expire time (like bans) where 0 seconds is a permanent permission key, but if deleted, expired or if max use is met it is gone. Maybe add a max use option when making a permission key, 0 being unlimited.

Added text to clarify that if a permission key is a added with no expire time and a max use limit that once that max use limit is met the key is deleted also. Using the idea that I made you could thing of permission keys as they work now having 0 for the expire time and 1 for the max use. The logic for determining use count could be very much like the enforcements indicator in the ban list.

Flow should be simple:

LPARAMETER passed_key AS STRING
'Check Key Process
DIM lbGoodKey AS BOOLEAN = FALSE
DIM liMaxUse AS INTEGER 
IF key_exist(passed_key)
	IF NOT key_expired(passed_key)
		liMaxUse = key_max_use(passed_key)
		IF liMaxUse = 0 OR key_enforcements(passed_key) < liMaxUse
			key_enforcements_increment(passed_key)
			lbGoodKey = TRUE
		ELSE
			'exceeded usage
		ENDIF
	ELSE
		'key has expired
	ENDIF 
	IF NOT lbGoodKey
		key_delete(passed_key)
	ENDIF 
ELSE
	'invalid key
ENDIF
RETURN lbGoodKey

(note: I wrote this off my head with no IDE and no debugging as just and idea)

[Erkunder]

No opinion or feedback from a TeamSpeak representative to this suggestion?

[Erkunder]

Shamelessly bumping my own thread.

[Erkunder]

Any reaction from a TeamSpeak representative wouldn't go amiss.

[dante696]

As you wish.....
A token / privilege key for multiuse was requested before from users on our public server (maybe it was screech, but can't remember), but this won't be added.

You should create a temporary group with b_virtualserver_join_ignore_password set. They never will see the password and you can invite them into that group.

[Erkunder]

A token / privilege key for multiuse was requested before from users on our public server (maybe it was screech, but can't remember), but this won't be added.

That really is a pity, because, as pointed out above, there are good reasons for this request. It would facilitate the use of generally private servers a lot. Could you outline your causes for turning this down?

You should create a temporary group with b_virtualserver_join_ignore_password set. They never will see the password and you can invite them into that group.

Unfortunately, this does not work: I copied the guest server group and changed the permission as you described. Invitation links for this newly created group still contain the server password.

But apart from this, your method could not substitute the above described temporary multi-use server key. You would still have to invite each random player/temporary guest individually, which would be a real pain in the arse if you are talking about, let's say, 10 people or more.

[Screech]

Unfortunately, this does not work: I copied the guest server group and changed the permission as you described. Invitation links for this newly created group still contain the server password.

Make sure your server group has ignore server password and remove the password from your bookmark to the server to prevent the password from getting placed in the invite.

[poisonpanik]

You would still have to invite each random player/temporary guest individually, which would be a real pain in the arse if you are talking about, let's say, 10 people or more.

Aren't you going to have to do this no matter what???

[Erkunder]

Make sure your server group has ignore server password and remove the password from your bookmark to the server to prevent the password from getting placed in the invite.

So the password that is contained in the invitation token is not necessary for this token to work, as long as the b_virtualserver_join_ignore_password permission for the invited group is set?

Aren't you going to have to do this no matter what???

No, I'm not. If it worked the way Screech and I described it, I would generate only ONE key that is valid for e.g. 10 UIDs and 5 hours after generating. I would then issue this key ONCE in the appropriate game channel (i.e. text chat channel in the game application, not a TS3 channel), so that the respective 10 users could read and use this key.

If dante696's method worked (unfortunatley, it did not when I tried it), I would generate 1 password-free buddy invite for each of those users, issue them individually via the private game channels and lose a lot of time that way.

Or, I do it the way I (and almost everybody else) handle it up to now, make a macro that posts TS3 IP, port and password and change the password and the macro whenever I notice that there are too many "unauthorised" visitors on our server.

The workaround that Screech has suggested was to add the legitimate permanent users (i.e. guild members) to a password ignore group and change the password regularly which wouldn't then bother the guild members. Drawback with that is that I would have to administrate each guild member individually which would be less effort than dante696's way, but still less efficient than with temporary multi-user server keys.

[poisonpanik]

playing devil's advocate here...

I would then issue this key ONCE in the appropriate game channel, so that the respective 10 users could read and use this key.

Wouldn't this require the user be on the server to start with? That defeats the point of having a key to get on the server then.

Drawback with that is that I would have to adminstrate each guild member individually which would be less effort than dante696's way,

Can't you add the ignore password permission to the server group instead of individual clients? That will make this a lot less time consuming than giving individual clients this permission.

[Erkunder]

Wouldn't this require the user be on the server to start with? That defeats the point of having a key to get on the server then.

I was unclear on this point. With "appropriate game channel" I did not mean a TS3 channel but a text chat channel in the respective game, i.e. the WoW raid channel.

Can't you add the ignore password permission to the server group instead of individual clients? That will make this a lot less time consuming than giving individual clients this permission.

This is what I was having in mind. I would have to add each permanent client to that group (some of them with multiple UIDs) or delete them from that group, respectively, when they left the guild or have been kicked. As we have more people that manage the guild than people that are capable of administrating the TS3 server, this method is rather unhandy.

Don't get me wrong, I do not state that we cannot use TS3 properly without the requested feature. But if my suggestion would be implemented, adminstrating the server would be much easier for people like me who use it as a generally private server with occasional visitors. And from my experience, almost any WoW guild's TS3 server is used this way.

[poisonpanik]

AH! lol

On your server do the guild leaders manage their server groups or does that require the server admin? If the guild leaders can manage the guild's server group this takes a bit of work off the admins on the server.