In this article we are going to explore the integration between a website’s login and SmartFoxServer’s login system, to avoid asking the player his/her credentials twice.

The scenario we’re working with is the following:

• the player opens the game’s home page and logs in
• after some browsing he hits “Play”, the game loads and the user is presented with another login screen to access SmartFoxServer

The objective of the article is to hide this last step, integrating the website’s session with SmartFoxServer, without sacrificing the security aspects.

» The problem of the double login

In the use case just described we are struggling with two separate systems (website and SmartFoxServer) that don’t share their state with each other, thus ignoring what’s going on in the other system.

From the surface it would seem intuitive that only the users who have logged in the website could play the game, so there is no need to double check the credentials in SmartFoxServer too, but this approach poses several security issues.

The most outstanding one is that SmartFox is running somewhere on a public IP address waiting for connections. Any decent hacker could figure out the address of the server and attempt to login from outside, bypassing the website’s login system. Since SmartFox isn’t setup to perform a credential check anyone could get in, even using the name of a registered users, thus impersonating the owner of the account.

» A convenient solution

This case looks very much like a “split brain” situation where one half of the system (website) knows about its users, and the other half (SmartFoxServer) knows about its users, but they don’t talk to each other.

To solve this state of affairs we need to make sure both systems are seeing the same state, which is possible by sharing the same data source. Since the a database is already an essential requirement to store user profiles and data, we only need a couple of simple additions to solve our split brain syndrome.

The following diagram illustrates the solution:

1. The client opens the home page and logs in:  a unique token (e.g. SHA-256 hash) is generated and stored in the session.
2. The token is also stored in the User’s profile on the database, together with the current IP address of the client.
3. The game is loaded.
4. Behind the scenes the game client connects to SmartFoxServer using the client’s username and the unique token as the password.
5. On the Extension side of SmartFox a check is done against the DB verifying that not only that the token is correct but also that the IP addresses match, for extra security.

With this simple system we essentially create an on-demand, temporary password that is shared among the two servers and works as a validator, together with the IP address.

The reason why we also use the IP of the client is to avoid that somebody eavesdropping on the communication could steal the token and use it to access SmartFox from his computer, which is presumbly has different IP address.

It is also highly recommended to use HTTPS for the website navigation and in particular for protecting the login phase.