🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Back to Networking and Multiplayer

Web API for a turn based game?

DrewDough · 2017-06-13T02:29:55

Hi, Wow. I haven't been here in a long time, and it's crazy to see this forum still thriving and people like hplus still around helping people. I am working on a prototype for a multiplayer mobile card game using Unity. I'm trying to finalize some architecture decisions. I was thinking of building the server as a Web API (using ASP.NET MVC) and having the client basically just GET and POST when needing to communicate with the server. I was wondering if people are using WebAPIs in commercial games and how sane of an approach this seemed. Since the MVP will not even support interacting with other players in real-time, it seems like this is going to be the simplest solution rather than creating a state based game server. Later, when we started adding features like 2 players being able to play against each other, I was thinking we could add a stateful game server at that time. Then, when players wanted to play against each other, the web server would do a hand off to the stateful game server 'players with ID x,y and session Id Z want to begin a match'. The game client would then connect to the stateful game server which would now be warmed up and ready to manage that interaction. This would accomplish 2 goals, 1) allow me to build only the bare minimum needed for the given requirements at a time 2) organically grow the server side as requirements are added 3) reduce the load and complexity on the servers so that they have a minimal amount of responsibilities. The service that does game logic doesn't need to manage friends lists and players news feeds. Any feedback on this approach? Thanks for the input!

Networking and Multiplayer Programming

Started by graveyard filla May 06, 2017 09:13 PM

15 comments, last by graveyard filla 7 years ago

graveyard filla

605

Author

June 07, 2017 09:13 PM

The problem with sending unencrypted tokens is that anyone on an open WiFi (such as Starbucks) is then vulnerable to session hijacking.
Check out the "firesheep" extension from a number of years ago, that finally shamed Facebook and such to move everything to HTTPS.
A randomly generated GUID is probably fine as a token, with the caveat that it has to be random, which then means it has less than 128 bits of entropy (because other parts of the GUID space are reserved for less-random unique identifiers.)
You might be better off with a long fully random number -- 128 bits is probably fine, 256 bits is plenty.
Another option is to use a predictable session id or game id or whatever, but issue a "ticket" that consists of (userid:gameid:issuetime:hash(userid+gameid+issuetime+secret_key))
"hash" might mean "sha256" these days -- sha1 is at this point broken-ish! The benefit of this kind of ticket is that you can detect whether the ticket has expired without a database lookup, assuming your servers are in sync on time (ntp is required.)
You can then go look up the appropriate player and game data based on the identifiers provided, rather than having to indirect through a GUID.
Something to think about.

hi hplus,

I'm struggling to find much information about creating TLS connection in Unity. I'm now doubting that games implemented in Unity (at least in general) are using TLS at all. Maybe I have the wrong keyword, but googling around for 'TLS connections with Unity3d' brings up almost nothing.

I want to make sure that my game is as secure as possible within reason. So my plan is to not do authentication on the actual Master Server or Game Servers, but instead create an HTTPS based 'AuthenticationService' for authenticating users in a completely seperate web application.

My plan is to expose an endpoint on an ASP.NET MVC app which will accept the username/password, as well as allow users to create new accounts.

Any time a user logs in, he will send in plain text his username/password to my AuthService, the AuthService will validate the user using Hashed/Salted PW (or maybe Scrypt, although need to learn more abbout that - as the Scrypt examples I saw did not expose the salt).

AuthService will then Generate a 128bit unique number and send it to the client.

Client will then drop connect and connect to the Master Server using his 128bit number. The MasterServer will call out to the AuthService to validate the 128bit number is valid. Once user is matched up to a game and connects to the GameServer, the same tokenID will be used to ensure the GameServer this is a valid connection.

Anytime a user connections to another server (chat server, game server, disconnect from MasterServer and reconnects) he will continue to send that 128bit number on the initial handshake and those servers will each call out to the AuthService to make sure the ID is valid and not expired passed reasonable timeframe (still TBD..).

Does this sound like a sane approach to you? Since I don't want to implement TLS on my game code, I think this should work OK.. The altnerative to using the AuthService in this manner is to I guess use the 'ticket' system you mentioned. I'm still not sure how that works though....

(userid:gameid:issuetime:hash(userid+gameid+issuetime+secret_key))

What is 'gameid' here? the unique ID of the game as in application title? or is a session ID that the auth service generates and stores?

What is secret key? Do you have a good keyword for this scheme for me to google and learn more about?

Or should I juse use the system I described above? Do you think there will be any issues when I add new auth providers such as Facebook?

Thank you again for your time!

FTA, my 2D futuristic action MMORPG

hplus0603

11,919

June 08, 2017 12:49 AM

If you're limited to Unity, you're limited to the security features they have built in, unless you literally impement well-known encryption protocols on top.
If you use HTTPS with the Web interface in Unity, that will use proper TLS, but the Unity low-level networking does not.
Then again, the low-level networking typically just does user agent movement, which typically is less interesting from a session hijacking point of voew.
Make your servers such that they use HTTPS for anything that affects the account (dollars, password changes, perhaps friends requests and messaging) and use the Unity networking for entities/movement, and you'll probably be fine.

enum Bool { True, False, FileNotFound };

graveyard filla

605

Author

June 12, 2017 07:40 PM

thanks hplus.. Is it OK from a security standpoint to re-authenticate for every single action when calling the HTTPS service for these actions? (e.g., no caching auth). I will probably use basic auth so that user can just use his username/password.

FTA, my 2D futuristic action MMORPG

hplus0603

11,919

June 12, 2017 07:55 PM

Is it OK from a security standpoint to re-authenticate for every single action when calling the HTTPS service for these actions? (e.g., no caching auth). I will probably use basic auth so that user can just use his username/password.

As long as you trust HTTPS, that's OK-ish.
Note that passwords in flight on the server or client are more susceptible to interception by people who have access on the end points.
For example, if you log each web request payload, that log might include the password.

Also, basic-auth is kind-of dumb, because you HAVE to go through the ugly web browser name/password dialog box.
An alternative is to have a field in your payload, something like:

...
  "auth":{"username":"bobo","password":"correct horse battery staple"},
...

Then you can later add auth:{token:...} if you want to support session-based authorization.

enum Bool { True, False, FileNotFound };

graveyard filla

605

Author

June 12, 2017 08:25 PM

Does basic auth imply UI? I thought basic auth just meant header based, where as your example the creds are POSTed in the body. The advantage to using headers is that you can GET and POST, where as with body based, you would need to include auth inside whatever you were POSTing, so if you did want to POST actual data, you'd need a slightly more complciated body.. No?

FTA, my 2D futuristic action MMORPG

hplus0603

11,919

June 12, 2017 09:40 PM

Does basic auth imply UI?

Well, not strictly necessarily, but usually.
What typically happens is that a web browser makes a request, that needs auth.
The server returns with 401 and WWW-Authenticate header.
The browser then shows a dialog box with the realm from WWW-Authenticate and a username/password field, and tries again.

If you make sure that every web request already has the appropriate username and password, then that UI is unlikely to be shown.
If you build a "single-page app" that prompts for this information, and then provides it in each XMLHttpRequest, and doesn't reload so it would forget about it, then that could work.

enum Bool { True, False, FileNotFound };

graveyard filla

605

Author

June 13, 2017 02:29 AM

Thanks man.. I'm still going to build the UI using Unity so I will be sure to include the credentials in each header by default. The Auth Service will manage the account related tasks as well as generate unique, 1 time use 128bit tokens for the Master Server to use to 'hand off' authentication to the game/chat/matchmaking services.

FTA, my 2D futuristic action MMORPG