Notice to all users

We are migrating towards a new forum system located at, as such this forum will become read-only on January 29, 2020

Results 1 to 4 of 4
  1. #1
    Join Date
    December 2009

    Oh God Please Help


    Try not to post too much but, using TS2 I had full DB integration, which is fine, username and passwords were gained form a mysql_table which was used for other things, the world was great.

    TS3, however with all this unique ID lark is really annoying, because I cannot figure out a way of setting up accounts for my users, nor properly authenticating them without either them or me having any input.

    Does anyone have a solution to making TS3 more like TS2 in terms of authentication, but without having to put workload on my users or server admins?

  2. #2
    Join Date
    December 2009
    I wrote two ideas how to solve this in this post:

    And a third idea:

  3. #3
    Join Date
    December 2009
    Somewhere in null...
    Well, here's an idea. It would require working with the tokens. Granted you wanted a solution that didn't involve them doing anything else other then registering their username/password with the website. However, we have to work with what we have.

    1) Have the website automatically generate a token for someone for the group you want them to be able to be in when they register, or get placed into a group on that website. (This is exactly what the serverquery and Token system was meant to be used for, as far as I can tell). Give this token to that user when they register or w/e the step is that you have for authenticating them against your TS servers.

    2) Now, this is where the part gets tricky, and I'm very unsure about. It might require some modifications from the TeamSpeak team, which isn't ideal, but in the long run it might be necessary. When the user uses up the token to gain those privileges, retrieve the uniqueID the token was used by and store it alongside of their username and password. Note: You might have to create a separate table that would have the following columns; forum-user-id|token|uniqueID

    3) Oh wait, You are banning them from your website or they are leaving. Whatever the case, the system can automatically go through, find their unique ID and strip it of all permissions.

    4) The user has now lost his unique ID for whatever reason (Disk Crash, Reformat, Dog ate his PC). Have a form in their account control panel that allows them to generate a new Token. You can make it so they can only generate a new token once every few days, or w/e. The point is they will be able to re-auth.

    Some cons with the above system:

    - You are depending on your users to be able to use the tokens. In most cases, this is unacceptable.

    - Your user can give their token to someone else. If you were handing out a server-admin token, that could be a really really big problem. Then again, due to the way the above method would work, you would still know the rogue Unique ID as it would have been associated with the users' account that the token was used on.

    - We are relying on a feature of TS3 that I don't think is even implemented. I didn't see anything in the documentation that would suggest the TS3 server even supports remembering which identity used which token. Hell, I haven't even looked at the the TS3 Database structure yet.

    - Someone manages to hack into their account by finding their password or w/e. They now have access to authenticating their unique ID as the above user, in which case you might accidentally ban someone when you trash all the unique ID's because of "mischief" or w/e. Then again, if their account username and password was compromised in the first place, they already had access to the TS3 server. This method just implements one more step to getting that permission.

    - You have to write all of the backend mechanisms to make this work. You would have to write the scripts to retrieve tokens, Unique IDs used with each token, storing the tokens, stripping admin groups. Etc etc etc. I also think it doesn't properly cover the aspect of, what if you assign them to another server group from the client, instead of the website. Your backend would have to be smart enough to recognize those changes for removal later.

    - Most of the fallibility with the above system, can still occur in your username/password environment.

    This is defiantly not a perfect solution, and depends upon functionality that I don't even know exists. However, it would... "roughly" allow you to use the current authentication system with what you have. Talk about fitting a square peg into a round hole.

    To be honest, No mater which way you look at it, The dev's either need to A) implement a legacy username/password system to work alongside of the current authentication system, or B) We are going to have to get creative on our own since option A doesn't seem likely with the attitude we have been receiving from them.


    Some more cons i was thinking of.

    Your users would be able to generate tokens for other people. This would kind of be like handing out their username and password to someone else to login. You would probably have to have the form that gives the user a new token to login, strip the permissions from any of the old ID's to ensure that users aren't handing out their tokens like candy to the noobs.

  4. #4
    Join Date
    January 2010
    Get the web script to only produce 1 token, this way they can't just hand out admin to many people.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts