Forum

Page 3 of 7 FirstFirst 12345 ... LastLast
Results 31 to 45 of 96
  1. #31
    Join Date
    October 2007
    Location
    Romania
    Posts
    35
    ok, based on what you suggested I see the things in this way.

    - a new table must be created in forum/whatever db that should contain a an userID and an associated token.

    - if an user is added to the forum/whatever and the registration step is successful a new token will be generated using srvquery and that token is inserted in tokens table with its associated userID.

    - if an user already exists and doesn't have a token assigned, we can provide in his profile page a method to generate a new token and assign it.

    - if an user already have an associated token we can provide him (in profile page for example) a TS3 url link

    - if an user gets banned/deleted we delete the associated token from the ts3 server.

    - and last thing (it should be first), buy a monkey to scratch my back of the head while implementing the things from above ( I hope you get the allusion )

  2. #32
    Join Date
    December 2009
    Location
    London
    Posts
    32
    I am shocked that you refuse to implement this simple solution, shocked.....

  3. #33
    Join Date
    December 2009
    Location
    Netherlands
    Posts
    33
    Quote Originally Posted by LuckyWS View Post
    I am shocked that you refuse to implement this simple solution, shocked.....
    You could also ask for the reason Maybe then you will understand their decision better (Like you, I also don't know the reason)

  4. #34
    Join Date
    December 2009
    Location
    London
    Posts
    32
    Quote Originally Posted by mvdstroom View Post
    You could also ask for the reason Maybe then you will understand their decision better (Like you, I also don't know the reason)
    Then I shall,

    given that the feature we require would be programatically very easy to add in addition to the token system, why not just do this for us.

    Were not talking small communities or clans here - We are talking large scale sites with many thousands of users, why make life difficult for us, it creates a weakness imho in the program and as such (since I believe TS3 will be extremely profitable) opens the doors for competitors to implement much friendlier solutions.

    I just dont get why you break this well founded technique of authentication.

  5. #35
    Join Date
    June 2002
    Location
    Krün / Germany
    Posts
    1,638
    so ether we mark this thread now as flame the devs or we try to work something out which does not have something todo with username/password.

    its your decision...

  6. #36
    Join Date
    June 2002
    Location
    Krün / Germany
    Posts
    1,638
    Quote Originally Posted by Hiigara View Post
    - if an user is added to the forum/whatever and the registration step is successful a new token will be generated using srvquery and that token is inserted in tokens table with its associated userID.
    the token can be set by you with a direct sql insert... you can put there what you want. the tokenadd command just does some random chars.

  7. #37
    Join Date
    December 2009
    Location
    London
    Posts
    32
    The U/P is obvioulsy not going to happen, but when u start sending the IP via serverquery I can fasion my own auth system on known users.

    It just feels like a dirty solution, and I mean no disrespect by that - but its not a flame, I think people have tried to relay the same point.

    I am thinking:

    -User Logs Onto Site, I get his IP + Username and Hash Them
    -User connects to TS using his Username as Nickname
    -I read the userIP, Nickname hash them and see if they match
    -All is good, otherwise, user is kicked

    This means that I can still have my username/pass solution, but not having access to the client IP via query is an issue right now - but one which I am sure one of you guys said you will be working on, if you can do it for the next beta ill give you a billion dollars and lots of lurrrve.

    PS : Not trying to make life difficult or flame, trying to work with you to find the best and most practicle scaleable solution.

  8. #38
    Join Date
    June 2002
    Location
    Krün / Germany
    Posts
    1,638
    could you explain to me why you dont want to use my listed token modifications?

    they would completly remove the need for your ip/username coding?

  9. #39
    Join Date
    October 2007
    Location
    Romania
    Posts
    35
    Quote Originally Posted by R. Ludwig View Post
    the token can be set by you with a direct sql insert... you can put there what you want. the tokenadd command just does some random chars.
    ofc I can do that but, for the sake of compatibility, I prefer not to have direct access to ts3 db but to use the existing methods provided by server query.

    No one tries to flame the devs here, we are trying to figure what automated auth solution can be implemented in TS3, till your previous post "assume the following..." we didn't had a viable alternative but to request the good old user/password combo that you categorically refuse to implement, now that you have given us an alternative things doesn't look so grim anymore.

    It's a good step forward what you suggested earlier, let's hope it will be implemented very soon.

  10. #40
    Join Date
    June 2002
    Location
    Krün / Germany
    Posts
    1,638
    the modifications were just an idea... maybe you got different or betters. (just not user....:P)

  11. #41
    Join Date
    October 2007
    Location
    Romania
    Posts
    35
    Quote Originally Posted by R. Ludwig View Post
    the modifications were just an idea... maybe you got different or betters. (just not user....:P)
    Well, anything that can establish an unique relation between a ts3 client and an existing auth system (hello LDAP/KERBEROS/whatever) should work, but, hello?! if I got it right a ts3 client (same user) can share different unique ids, nasty thing.

    Another idea is to implement an "external auth plugin system" within ts3 server. Don't get me wrong, whatever the input will be, that "module" will only serve as an external mandatory pre-auth method and that auth will happen exactly at connect time using the current data sent by client ( as it is, the current ts3 client connect dialog is more than enough ). Nothing more. If that auth module gives its ok we continue with the normal behaviour.

    I think this idea is the best possible , your suggested modification for example can be easily implemented in a separate auth module without complicating the server/client code.

  12. #42
    Join Date
    December 2009
    Location
    Germany
    Posts
    2,354
    Here are also some ideas I wrote down in the last weeks in this forum:
    http://forum.teamspeak.com/showpost....80&postcount=2

    And a third idea:
    http://forum.teamspeak.com/showpost....0&postcount=11

    Maybe something is usable for you. From the first link the first idea is working on our clan homepage since last week.

  13. #43
    Join Date
    December 2009
    Location
    Switzerland
    Posts
    439
    Quote Originally Posted by R. Ludwig View Post
    i am sorry guys but we wont add username/password authentication to ts3.

    so assume the following:

    you could create a token which does the following on usage:
    • give the client the needed permissions
    • set (for example) client_description to something you could work with (username? user_id? customer_id?)


    server:
    • accepts tokens while initiating a new connection
    • provide command to find clients via (for example) client_description


    the client connect dialog/boomark dialog:
    • gets an extra field where you could put a token


    ts3 url link:
    • can accept a token


    new ts3 url link:
    • for creating a ts3 bookmark (with token)


    that should cover all your problems, it would even make it obsolete
    to write some sort of manual for your users and shoud solve alot of
    problems at general.
    First of all:
    Thank you very much for considering this to be a weak point at the moment and for your suggestions

    If I can add a "username" to the token and this field can be used to search clients in ServerQuery all the problems would be solved.

    But I would not use the client description field for this purpose. Better add a new field.

    This would completely solve the problem as there is a way to match a TS ID to my own ID.

    The server accepting tokens on connect or the link with a token to connect and add a bookmark would be even better But it's not absolutely necessary

    If you implement this I will be 100% convinced of the new authentication

  14. #44
    Join Date
    October 2008
    Location
    Alberta, Canada
    Posts
    166
    Quote Originally Posted by Hiigara View Post
    The solution might be very simple to implement.
    server side
    using the following columns from "clients" table -> client_login_name and client_login_password

    client side
    using current connect form, if the user supplies a password in that form then on server side we will have 2 possible cases.
    1. the user supplied the server password
    2. the user supplied his own password for his account identified by submitted nickname.


    a short pseudo code at auth time server side

    // client_submitted_username / client_submitted_password -> provided by the client when connecting to ts3 server.

    if (client_submitted_password == NULL && SERVER_PASSWORD == NULL) {
    client_nickname=client_submitted_username;
    return AUTHED;
    }
    if (client_submitted_password == SERVER_PASSWORD) {
    client_nickname=client_submitted_username;
    return AUTHED;
    }
    else {
    client_password= querydb("select client_login_password from clients where client_login_name=client_submitted_username");
    if(client_password == client_submitted_password) {
    return AUTHED;
    }
    else return NOT_AUTHED;
    }


    This method does not change a thing in TS3 client , only in the server by adding an extra check at auth time.

    Example:
    User X connects using password Y
    server side auth , if password Y = server password then we let him in, if not
    we check if there is a user X in clients table, if true check the password Y against the password from the table, if true then we let him in, if not we finally disconnect the user with a nice error message.
    I like this solution except for one thing: What if you don't want your username and nickname to be the same? Not possible with this solution. You would have to create another table stating all usernames and their associated nicknames and on login, set the nickname to whatever is in that table. Then, you'd need to provide an external method to change your nickname in that table.

  15. #45
    Join Date
    February 2009
    Location
    The Netherlands
    Posts
    17
    What we need (which the current single-time token system does not cover):
    - Some way to create a token and a userID/userName combination via serverquery and assign server groups to that token (must be possible before the client ever connects/registers to the TS3 server).
    - When a client connects (and registers to the server) and uses that single time token, he will get access based on the assigned server groups and his property field userID/userName is set to the given userID/userName.
    - It must be possible to search registered clients on the userID/userName property field.

    We also need the following requirement for the extra field:
    - The userID/userName property field (which we need to identify - not only in real time - a user between TS3 and external system/forum/cms), must not be editable by the connecting client himself (unless maybe if it is empty), only by server admin(s).

    Reason for this requirement:
    - Prevent clients from faking in TS3 that they are a different user than the one we have in our external system/forum/cms

    Possible extra requirement:
    - The userID/userName property must be unique (if set?)

    Two extra questions:
    - Can you provide us with a valid argument why you will not introduce a username/password system into TS3?
    - Can you provide us with a valid argument/reason why you wanted that Channel Admins can create subchannels everywhere in comparison to the old TS2 situation that this permission was only valid for specific channels for which they were assigned channel admin?

    To me, it seems, that there is really a big gap between what the devs decided to develop and what the average server admin wants in permission and authentication... Did the devs ask their customer base (old TS2 server admins) before developing if it was a good idea?

    The token system has its specific purposes/benefits but it does not cover the needs...
    Last edited by MindcrimeNL; January 7th, 2010 at 01:03 PM.

Thread Information

Users Browsing this Thread

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

Similar Threads

  1. [Need help] Simple user support system.
    By Karol1814 in forum Server Support
    Replies: 3
    Last Post: September 18th, 2014, 09:48 PM
  2. last user login data & preexisting user table
    By Valsimot in forum Server Support
    Replies: 1
    Last Post: January 30th, 2012, 10:44 PM

Posting Permissions

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