Handle in-game routing?

[Tej]

Hi! This is not a specific openfl question althought I do use openfl sockets!

I’m working on a small multiplayer prototype and figured I’d involve a database to store users in. I’ve chosen to go with a mongodb server just because I’m writing the back-end in Node.

What I’m curious about is how do games(and how should I) handle routing? From a login screen to rendering the game. I image it’s a big difference between routing on a website and routing in a game.

How should I approach this?

When i’ve prompt the user with an option to login, and the credentials are authenticated on the server and the response is sent back to the user, then what?

I’m having a hard time searching for this particular answer
Thank you!

edit: The only way I can think of, is to listen to the server response and act on that such as this:

`Client.login => Server.Authenticate(Username/password)
Server.response => Client

if(response) {
renderGame();
}else {
throw error(‘You were not authenticated on the server’);
}
`

But I doubt that this is how its done and I can see a ton of security issues with this approach? Or am I wrong?

[maitag]

For web-apps with user-auth/management good approach is to send username+password over ssl encrypted connection first.
Server is generating unique random ID after succesful login and send these uuid back to user to open new “session”
So later communication with server needs only these uuid inside every user-message, to let server know about -> who is still authenticated (after amount of no-communication-time, session-id should be deleted by server automatically).

[Tej]

Oh sorry, i should have made it clear that its not an web-app i’m programming, its a windows client (a game) but perhaps the primciple’s the same?

[bubba_169]

Most apps including Facebook use the same approach. They call the random strings access tokens and you have to send it back to them with every request otherwise you will be rejected. For a client I presume you’d check for a valid access token on startup and if not get them to log in using a connection to your server. You’d then store your token that you get from the server for future requests / logins.

[sundialservices]

Also: even if you’re not creating “a web server,” the HTTP protocol (and an HTTP server, such as Apache) is still a very-common way to deal with this.   (And it probably does not matter whether you use Mongo or an SQL server.   In fact, precisely because it is a separate server (process) than your Apache server, SQL might be better …)

When the user successfully logs-in, the server creates a “session” record in some table, identified by a key consisting of a random string or number.   All requests (other than “login”) must be accompanied by a valid string corresponding to a logged-on session.   The entire game-state relating to this user’s session can be conveniently stored here.  

The session-table record also should contain a time-stamp when the record was created and when it was most-recently referenced.   Some kind of “garbage collection” procedure runs now-and-then to clean up abandoned entries in this table.

Finally, the really good news is that “all of this has already been done for you!”   Session-handling, JSON, so-called “RPC = Remote Procedure Call” toolkits, and so on.   Your server would be “a web server” that never serves an HTML page, and that will never be asked to do so.   Instead, it receives “RPC requests” (say, in JSON) from its clients, and responds to them in-kind.   All of the “messy plumbing” needed to do all of this, is something that you don’t have to write yourself.

It is always wise to use SSL for all connections to any server.   (As a routine practice, don’t send traffic over any network “in the clear.”)   If you delve a little deeper than just the surface-level into the whys and wherefores of the SSL protocol, you will also discover that SSL can (through “digital certificates”) be used to verify that only your application can successfully connect to your server … at all.   (Ordinary “secure web sites” typically do not avail themselves of this feature, but it exists …)