How to make a Login system on Unity + WordPress

Unity is one of the most popular game engines, and wordpress is the indisputable king of CMS, being used in nearly 1 billion websites(43% of the entire web). Because of their popularity, it’s common that people will want to integrate both: have a wordpress website where people can make an account and integrate it with their Unity(say, for example, to upload saves to their servers, handle purchases, etc). In this article, we will go over the basics on how to make both work together.

WordPress’ side

The simplest way to communicate between unity and wordpress will be through a HTTP GET request. With it, unity will basically stablish a connection to the server, then communicate what it needs from it. On the wordpress side, you’ll have the following example code:

function unity_endpoint($creds) {
	global $wpdb; //function from wordpress to handle mySQL calls, in case you need
		
		//grabs credentials from fields 'username' and 'password' in the URL
		$username=$creds['username'];
		$pass=$creds['password'];
		
		if(!is_wp_error(wp_authenticate($username,$pass))){
			
			$data='Some data to send to unity'
	
			
			echo $data[0]->data;
			die();
			
		}
	
}
//add action to run on a GET request to yourwebsite.com/wp-json/myapi/v1/text?username=name&password=password
//you may add extra parameters by adding &parametername=value at the end
add_action( 'rest_api_init', function () {
  register_rest_route( 'myapi/v1', '/text', array(
    'methods' => 'GET',
    'callback' => 'unity_endpoint',
  ) );
} );

This basically makes it so whenever some accesses the website, in that specific endpoint, the function “unity_endpoint” will get called, receiving the credentials from the URL. Then it checks those credentials using the wp_authenticate() function(that returns either a wordpress error class or true, thats why I’m using !is_wp_error() to check) and if they’re correct, then you can do something on the server and even respond to the client using “echo“. I advise also closing the connection using die() right after, just in case.

Unity’s side

On the unity size, the code will look like this:

IEnumerator GetRequest(string uri)
    {
        using (UnityWebRequest www = UnityWebRequest.Get(uri))
        {
            yield return www.SendWebRequest();

            if (www.isNetworkError || www.isHttpError)
            {
                Debug.Log("Error")
            }
            else
            {
                Debug.Log(www.downloadHandler.text);
               
            }
        }
    }

A IEnumerator is basically a function that can be handle asynchronously(you can use “yield return new WaitForSeconds(time as float value);” to make it wait for a certain time before continue executing). On it, we’re using UnityWebRequest to make the HTTP GET request. If the connection is sucessful, unity’s console will spit the text returned by the server, if it fails we will get a “Error” message. To call it, use StartCoroutine(GetRequest(“URL”)).

What then?

With the two sides setup, you can do pretty much everything. You can make a save system where upon login, the player can upload their save to your database, you can make a highscore system like my game Humanity Clicker has, a friends system, anything. Keep in mind though, that without a SSL certificate, anyone can obtain the credentials of the client fairly easy with a man-in-the-middle attack or similar tactic, as the certificate ensures that the connection between client and server is secure and encrypted.

Keep them connected

In order to keep the user logged in for at least a few days, in a safe way, you might implement a session system. The way it’d work is simple: Once the client logs in, the server grabs their IP, and generates a fairly long string of random letters, numbers and special symbols called a token. The server then sends it to the client and now, whenever the client wishes to do anything with the server, they’ll send the token and the username to the server alongside its request, and it will check a mySQL table for the name, IP of the connection, token value and date of its creation. If name, IP and token all match, and the creation time isn’t too old(say, bigger than 30 days) the server just, believes that to be the actual user and executes the action. If anything doesn’t match, it refuses(and alerts the user of people trying to log in to their account). For extra security, you can lower how long the token lasts and even remove it from the database(forcing the user to log in again) in case too many attempts at using it by another IP are made. You may also store other identification data on top of IP to further increase the difficulty of faking a login, such as device name and whatnot.