Best Method' for connection exchange.
by Nathan Huffman · in Torque Game Engine · 05/25/2006 (8:52 pm) · 7 replies
What would be the best method to complete the following 'transfer':
User logins in via login server, and is successfully authed.
User gets 'transfered' to game server (different physical PC)
Do you just send data to the client to disconnect from the login server and connect to the IP of the 'game server' with some specific information being supplied that the login server provided to permit the connection? (like a temp password)?
How is this typically done?
User logins in via login server, and is successfully authed.
User gets 'transfered' to game server (different physical PC)
Do you just send data to the client to disconnect from the login server and connect to the IP of the 'game server' with some specific information being supplied that the login server provided to permit the connection? (like a temp password)?
How is this typically done?
#2
After they are authorized, they can see a link to start the game. When they click the link, a ticket GUID value is added to a table in the db, along with some user information. That ticket is only good for 1 minute. The Ticket GUID is then passed to the game via a command line argument, and when torque starts, it then checks for that ticket in the database, and if it is there and not expired - the game gets the user info from that table and begins.
This way all authentication is handled for me by DotNetNuke. The game has to have ODBC database access of course. And there is are registry entries that your game installer needs to make to allow the game to be launched by a web link (this is normally not possible due to security issues - but a registry entry for your game allows it.) I know this will work for Windows, but have not researched its feasibility for other platforms.
This method works well for me because the game community site is a DotNetNuke site already. Also DotNetNuke has built in monthly fee systems using Paypal and other merchant services systems that give the user a particular security role when they sign up.
The basic design is there, and I have verified that the web link will work. I have not completed the implementation yet though. If anyone is interested I'll post the links to the ODBC torque stuff I'm using, as well as info on the registry entry needed.
James
05/26/2006 (10:49 am)
I worked out a nifty design to have the user login to a DotNetNuke web portal (thus the portal is handling all authentication), and it has a full-featured role-based security scheme using Microsoft's best practices.After they are authorized, they can see a link to start the game. When they click the link, a ticket GUID value is added to a table in the db, along with some user information. That ticket is only good for 1 minute. The Ticket GUID is then passed to the game via a command line argument, and when torque starts, it then checks for that ticket in the database, and if it is there and not expired - the game gets the user info from that table and begins.
This way all authentication is handled for me by DotNetNuke. The game has to have ODBC database access of course. And there is are registry entries that your game installer needs to make to allow the game to be launched by a web link (this is normally not possible due to security issues - but a registry entry for your game allows it.) I know this will work for Windows, but have not researched its feasibility for other platforms.
This method works well for me because the game community site is a DotNetNuke site already. Also DotNetNuke has built in monthly fee systems using Paypal and other merchant services systems that give the user a particular security role when they sign up.
The basic design is there, and I have verified that the web link will work. I have not completed the implementation yet though. If anyone is interested I'll post the links to the ODBC torque stuff I'm using, as well as info on the registry entry needed.
James
#3
If I read what you're saying correctly, it sounds like a serious security flaw if the client has ODBC access to your master DB? Is this what I'm understanding?
Even if you nerfed the public account... it could be comprimised.
Not to drag on - maybe I misunderstood?
05/27/2006 (1:53 pm)
I'm not sure if I completely follow what you're doing, James. However, I'm half-interested (half because my project isn't going that way but...)If I read what you're saying correctly, it sounds like a serious security flaw if the client has ODBC access to your master DB? Is this what I'm understanding?
Even if you nerfed the public account... it could be comprimised.
Not to drag on - maybe I misunderstood?
#4
05/27/2006 (3:51 pm)
Yes a ODBC connection is a major security risk and not something you would want to publiclicy want everyone to access. What you want to do is to make the game server do the auth. The game server can have any open odbc or other connection it want.
#5
05/27/2006 (8:57 pm)
Exactly. I'm refering to the game server hitting the DB, not the client. When the client makes the connection to the server, server code looks for the ticket in the DB and either allows the connection or denies it.
#6
All it requires is a bit of study of the connection sequence, an understanding of setConnectArgs(), and a pull from the connect args to get the session token/ticket from the client, compare it to the "pending authorization" tokens/tickets sent over by the login server, and you are set.
05/27/2006 (11:08 pm)
In fact, this is an excellent design for a very secure setup. He never has the player send across login/password to the Game Server at all, but has the client send up a session token (he calls it a ticket), and the server has already been notified of the pending ticket, and can authorize the new connection and give the proper connectivity to that user's database data.All it requires is a bit of study of the connection sequence, an understanding of setConnectArgs(), and a pull from the connect args to get the session token/ticket from the client, compare it to the "pending authorization" tokens/tickets sent over by the login server, and you are set.
#7
1. You login to the DotNetNuke site - this is very secure because it uses the latest security standards.
2. Because you are assigned a security role of say, My Game Gold Edition, you see the link to "Start My Game". This link shows up in a DotNetNuke module, which is an ASP.NET program embedded into the DotNetNuke page.
3. When you click the link:
a. The module generates a random Global Unique Identifier (GUID) and adds that value to a table, along with that user's ID and any other session information that is appropriate. The GUID is the session token that Stephen talked about, and that I called a "ticket". There is a "time to live" value also in that record, which could be 1 minute perhaps.
b. The module link starts the Torque client and passes that session token GUID to it as a command line parameter.
4. The client passes that Ticket to the server when it attempts to make a connection.
5. The server does a select from that session token table, looking for that GUID and a time to live that hasn't yet expired.
6. If it finds it, the server gets the other information about the session from that table record, like the user ID, etc, and allows the connection.
7. If it doesn't find it, the server denies the connection.
This way, the only thing going back and forth between the web page, the Torque client, and the Torque server - is that random GUID session token.
If anyone is interested, when I'm done writing the DotNetNuke module and Torque code to get this functional, I'll post it so others can use it.
05/28/2006 (9:59 pm)
Thanks Stephen - this is sometimes hard to explain. Here it is in more detail:1. You login to the DotNetNuke site - this is very secure because it uses the latest security standards.
2. Because you are assigned a security role of say, My Game Gold Edition, you see the link to "Start My Game". This link shows up in a DotNetNuke module, which is an ASP.NET program embedded into the DotNetNuke page.
3. When you click the link:
a. The module generates a random Global Unique Identifier (GUID) and adds that value to a table, along with that user's ID and any other session information that is appropriate. The GUID is the session token that Stephen talked about, and that I called a "ticket". There is a "time to live" value also in that record, which could be 1 minute perhaps.
b. The module link starts the Torque client and passes that session token GUID to it as a command line parameter.
4. The client passes that Ticket to the server when it attempts to make a connection.
5. The server does a select from that session token table, looking for that GUID and a time to live that hasn't yet expired.
6. If it finds it, the server gets the other information about the session from that table record, like the user ID, etc, and allows the connection.
7. If it doesn't find it, the server denies the connection.
This way, the only thing going back and forth between the web page, the Torque client, and the Torque server - is that random GUID session token.
If anyone is interested, when I'm done writing the DotNetNuke module and Torque code to get this functional, I'll post it so others can use it.
Torque Owner Martin de Richelieu