Accessing Server API from HISE

gorangrooves

@ustk Thanks very much! Hopefully, this will be a good-enough pointer to make it happen
Am I correct to assume that we would need to recompile HISE with this module included?

ustk

@gorangrooves Any change in the sources needs a new build to be effective (at least for the APIs though...)

gorangrooves

@ustk Thank you. This should give us a pretty good direction.

Christoph Hart

Maybe I can wrap the stuff I wrote for PercX into some Scripting API calls.

It could be a minimal API to be as generic as possible, but should be able to handle session cookies for user authentication:


// Use a RSA key to encrypt the login data
var myprivatekey = "512.ljsdnvlkjnldsfkjvlkjdflkvjnsdfvkjnldkvbdfvdf";
var mypublickey = "512.lkdncfdlkjfnvlkjsdnflkjvnbsdjhvasldfiaslkdnv";
var credentials = Server.getLocalCredentials("credentials.dat", mypublickey);

if(!isDefined(credentials))
    credentials = { "user": "AAX/VST SDK", "password": "4321" };

if(isDefined(credentials))
{
    // Call a login function on your server
    Server.login("https://mysite.com/login", credentials, function(status, response)
    {
        // Any HTTP request will return 200 as status code for OK
        if(status == 200)
        {
            // Save the credentials to a local file
            Server.storeCredentials(credentials, myprivatekey);
            // Store the session key into the cookie.
            cookie = response;
        }
    });
}

// For each authenticated call you need to pass in the cookie plus a callback
Server.call("https://mysite.com/getuserinfo", cookie, function(status, response)
{
    if(status == Server.StatusOK) // = 200
    {
        // do something with the response
        // (probably a JSON object)
    }
    else
    {
        Console.print(status);
    }    
});

However this requires some proper coding on the server backend to handle cookies and do proper HTTP responses.

d.healey

@Christoph-Hart Yes please!

ustk

what do you guys think about:

Checking account via the internet at every session (so needs permanent access, which might suck)
Or storing a unique license file on the client-side after activation (but a naughty customer might still keep the file for after a refund/cancel action)

d.healey

@ustk said in Accessing Server API from HISE:

Checking account via the internet at every session (so needs permanent access, which might suck)

I won't buy it.

Or storing a unique license file on the client-side after activation (but a naughty client might still keep the file for after a refund/cancel action)

I also won't buy it :) but it is the lesser of the two evils (still evil though :p ).

ustk

@d-healey I find the 1st dumb...
But what is you think is bad in the second? Is it not Christoph's principle above?

d.healey

@ustk said in Accessing Server API from HISE:

But what is you think is bad in the second? Is it not Christoph's principle above?

I didn't look at Christoph's implementation, my use for server communication is not for restricting the user, I mainly want it to alert them to updates and provide an easy download interface.

ustk

@d-healey So are you against a license activation system? without that you can distribute freely your product I think... :)
I don't see restriction where you just want an activation of the product

d.healey

@ustk

So are you against a license activation system?

Basically, I'm anti-DRM.

Christoph Hart

Requiring an internet connection each time you load the plugin is an absolute no-go.

Or storing a unique license file on the client-side after activation (but a naughty client might still keep the file for after a refund/cancel action)

This is the way to go and don't bother about the naughty client, think about the legit customer who wants to use your plugin without Wifi access..

d.healey

@Christoph-Hart said in Accessing Server API from HISE:

This is the way to go and don't bother about the naughty client, think about the legit customer who wants to use your plugin without Wifi access..

Why does the legit customer need restricting, unless they're naughty. ;)

LightandSound

@d-healey you can do an a cheap and dirty update approach. Juce has an easy way to read a URL result as a text string and compare it with an input string, so you can just stick a .txt file on your site (hidden of course) and literally just have the text as the version number and match it against the current version. Whenever you load the plugin it can check that result against the internal version number and display it if needed. Just means you need to remember to update the text file.

Similarly you can do this for file activation for online list of CD keys, and it helps you to be able to disable any cd keys that are chargebacked/refunded. For this you probably would want credentials though, as having a publicly available list of keys is not really ideal :p

I might implement this in to my public branch once I'm finished with this chunk of work on release triggers

Christoph Hart

Because there are different levels of naughtiness and you want to prevent the moderately naughty customer to just upload it on some filesharing hoster.

Everybody has to find a solution that matches his paranoia and mine is a simple license scheme that prevents passing around a single copy across different computers without restriction, but I know there is a spectrum that spans from @d-healey to PACE :)

ustk

@d-healey The solution lies in the payment form, just add a "I am a naughty customer" checkbox :)

d.healey

@ustk said in Accessing Server API from HISE:

@d-healey The solution lies in the payment form, just add a "I am a naughty customer" checkbox :)

I'm very tempted to implement that technique.

ustk

It takes weeks if not months to take the plunge of buying a plugin (at least I am)
Then 20min to actually buy it
Then 1min to hours for the download
Then 1-10min for the install/running
Then 30sec to type the credentials
Then 5-10sec to click activate and wait for the result...

Lindon

@ustk said in Accessing Server API from HISE:

Then 5-10sec to click activate and wait for the result...

All true but it's this last bit - a lot of customers are suspicious of what you are communicating to your server....

Frankly "calling home" schemes put off a large number of users - Christoph is right the local key solution is best - its the one most users can live with.

Christoph Hart

@Lindon said in Accessing Server API from HISE:

All true but it's this last bit - a lot of customers are suspicious of what you are communicating to your server....

That should be one of the advantages of the GDPR stuff - you need to tell them what data you gather and it's plain illegal if you collect more, so unless your customer suspects you of breaking the law, there's not too much room for suspicion.

Accessing Server API from HISE

42

1.7k

11.7k

101.8k