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:
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).
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.
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 ā¦)