(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.