Forum QuickConnect Quick Connect Login System and Validating Requests on Server

Discussion and help relating to PlayerIO's QuickConnect feature, including Facebook Connect and Kongregate Connect.

Quick Connect Login System and Validating Requests on Server

Postby ZoopTEK » July 21st, 2013, 5:05 pm

(This thread was insightful, but I didn't want to hijack it: quickconnect/quick-connect-and-security-concers-t34934)

I have done some multiplayer games before, but very new to Player.IO.

I am specifically speaking to just logging in and doing basic player profile stuff, I am not even getting to the actual gameplay yet:

In my little demo, I have:
1. Client connects via Player.IO.
2. Client can start adding/modifying BigDB objects.

This seems highly dangerous to me. If someone reverse engineers the client (always a possibility), or even just nab the log in sequence, they could easily call the BigDB functions themselves and have full power over the database. Obviously a terrible strategy, but at least this demo got me acquainted with how Player.IO functions.

It seems like this is what I should do for the long haul, but this is what I want to clarify:
1. Client connects to Player.IO multiplayer server.
2. Client sends their login information (password hashed of course) to the server.
3. The multiplayer server authenticates the player.
4. The multiplayer server says the player is in.
5. The player must request the server to do any substantial action, such as purchasing an in-game item, where the server validates the request ensuring it is legit.

Is this how you intend Player.IO to be used? The player is not even playing yet (just profile stuff), but to be safe, I should essentially make a multiplayer server for that sole purpose of validating any and all requests, even basic profile management stuff.

For clarity, here is a real-life example: in our game, we have a numerous editors, where a player can "sell" their items for in-game currency. Another player can find those items on sale, and purchase them. Without an intermediate server double-checking anything, a compromised client could easily manipulate the database and do anything they want, including purchase the item for free.

Thanks in advance for the clarification. I really like Player.IO. It's very elegant.
ZoopTEK
 
Posts: 6
Joined: July 18th, 2013, 2:26 am

Re: Quick Connect Login System and Validating Requests on Se

Postby Henrik » July 22nd, 2013, 8:49 pm

Player authentication is done through Connect or QuickConnect. (We highly recommend QuickConnect, it's secure and easy to use)

Once a player is authenticated, you can start using the client-side API, in which case all the access controls are applied, which means that normally a user can only edit BigDB objects they've created, and they can only access the secure functions of PayVault, which means they can't edit other player's objects, or give themselves unlimited coins or items.

Also, once authenticated, they can connect to one (or more) Multiplayer rooms, and start sending messages to that. There's no authentication in this step, it's already taken care of, but it's up to you to write server-side code that uses the server-side full-access APIs to implement what you need for your game.

So in the case of your trade, you would have both players connected to the same room, some messages back and forth to establish what item to trade and that both are ok with it, and then you can modify each player's inventory directly.
Henrik
.IO
 
Posts: 1832
Joined: January 4th, 2010, 1:53 pm

Re: Quick Connect Login System and Validating Requests on Se

Postby ZoopTEK » July 22nd, 2013, 9:45 pm

Thanks for your response; exactly what I needed clarification on:

  • For anything related to editing one's own BigDB object's, client modifying BigDB directly is probably safe.
  • For virtual items bought with tokens (real money value), calling the PayVault functions from a client probably safe.
  • For anything related to cross-player activities, such as purchasing each other's items (with fake money), use the multiplayer server to act as a intermediary.

Awesome, thanks!
ZoopTEK
 
Posts: 6
Joined: July 18th, 2013, 2:26 am


Return to QuickConnect



cron