This tutorial will take you through the motions of creating your own online service for Release Manager to connect with.

There are three parts to making this work. You need to set up your online service. You need to configure Release Manager to call your service and lastly you might need to pass your Release Manager session into your game.

The post service works by sending a post instruction to a web service and reading the response either a 200 for success or anything else is a fail. Additionally all cookies sent back will be added to your Release Manager properties and can be passed to your application.

<?php

function SendDeny($message = "Invalid Username/Password"){
    header('HTTP/1.1 403 '.$message);
    exit();
}

function SendOk($session){
    header('HTTP/1.1 200 Ok');
    setcookie('Session', $session, time() + (86400 * 30), "/");
    exit();
}

$username=$_POST["username"];
$password=$_POST["password"];

if($username == '' || $password == ''){
    SendDeny();
} else {
    $session=null;

    // CODE TO AUTHENTICATE USER AND CREATE SESSION HERE

    if (!isset($session)){
        SendDeny();
    }

    SendOk($session);
}

Line 3-6 shows how we return a Deny. We send a 403 with the message behind it. That message will be available in Release Manager after the failed login.

Line 8-11 show how we return a 200 with the session as a cookie. You can send as many set-cookies as you want all of them will be added to Release Manager's properties on return.

Line 14 on. We pull the two parameters from the post. For now these can not be changed. We will make the system more flexible over the next few releases.

At line 22 you would need to add the code that does the authentication, most probably by hashing the password and doing a database lookup. This part is up to your developers.

After that the system either sends a deny or an ok.

First you will need to set up a login group. Groups are a new features where items are placed together and can be shown or hidden based on events in the system.

In the above image you can see the login group that has been defined. The login group is all the items needed to perform a login.

These text fields must both have specific property names. These names are passed through as username and password to the post. To keep things simple they need to be username and password all lowercase.

The group needs to be visible when you have not logged in. You can see the settings needed for that. Groups can have a variety of display conditions and using them gives you the ability to really customize your users experience.

To aid in the group display rules the system has a preview state shortcut. You can change the login status and the various other statuses in the drop down. This aids in creating your launcher.

The login button for post needs to be configured as follows.

You need to select a Login button of type post.

Your fully qualified url. You must make sure your URL is an https with a secure certificate (The certificate provider must be one that supports Java 1.8).

Once configured you can test your login with the test fields and button. It will show you the response from your service and what cookies were returned and how they will be added into the Properties.

You can see that Post.Session is added to the properties as that is what is returned as Session from our cookie.

As you can see the property Post.Error is added. You can then include that in a label on screen as ${Post.Error} it starts off empty and will clear each time Login is pressed.

There are two options on how to pass the session (or any other values) to your executable. You can add them as a command line or you can set a system variable. The image below shows you how to do both. Keep in mind each line of the box command line arguments is a new argument, this allows you to pass strings with spaces as a single argument.

The top box sets a system environment variable called session to the value in your Session cookie returned from the post. Alternatively you can set the first command line argument to the same session. We don't recommend using the command line if you can avoid it as we also pass a multitude of values to it for configuring the screen resolution and other settings for some games.

You can read more about environment variables here https://msdn.microsoft.com/en-us/library/system.environment.getenvironmentvariable(v=vs.110).aspx

For more on reading command line arguments see https://msdn.microsoft.com/en-us/library/system.environment.getcommandlineargs.aspx