Forum QuickConnect Option to Save PlayerIO access tokens

Discussion and help relating to PlayerIO's QuickConnect feature, including Facebook Connect and Kongregate Connect.

Option to Save PlayerIO access tokens

Postby vikreed » December 20th, 2017, 9:56 am

Hi,

To speed up login process and also to avoid getting user details multiple times, we should have an option of storing Access token(generated after PlayerIO authentication) of player in mobile devices. This way, next time the user opens the app, he should be already authenticated in the app, instead of doing authentication everytime he opens the app.

I guess most of the world has moved this way. Most of my competitor's apps login in few seconds and our app takes too much of time. I definitely need to improve in many more areas but this can also save 1-2 seconds for sure.

Let us know if this seems feasible.

Regards,
Vikreed Team
vikreed
 
Posts: 23
Joined: September 30th, 2017, 8:02 am

Re: Option to Save PlayerIO access tokens

Postby zodern » December 21st, 2017, 3:22 pm

This would be very useful for my game too.

Right now, the access tokens expire after around an hour, except for the JavaScript client. Maybe there can be a new method to request tokens that expire in 90 - 180 days? Games can request new tokens each time they log in, so unless if the user is gone for a few months the stored token will be valid.
zodern
Paid Member
 
Posts: 1
Joined: April 12th, 2016, 10:40 pm

Re: Option to Save PlayerIO access tokens

Postby vikreed » December 28th, 2017, 9:31 am

Hi, Any thoughts on this?
vikreed
 
Posts: 23
Joined: September 30th, 2017, 8:02 am

Re: Option to Save PlayerIO access tokens

Postby Henrik » January 1st, 2018, 8:49 pm

What's the primary authentication method for you user?
Henrik
.IO
 
Posts: 1827
Joined: January 4th, 2010, 1:53 pm

Re: Option to Save PlayerIO access tokens

Postby vikreed » January 2nd, 2018, 6:43 am

The Basic one.

PlayerIO.Authenticate(
"[Enter your game id here]", //Your game id
"public", //Your connection id
new Dictionary<string, string> { //Authentication arguments
{ "userId", "bob" },
{ "auth", "1265646201:fe26201c4f1076ae23093d8764cf62e6c5246105" },
},
null, //PlayerInsight segments
delegate(Client client) {
//Success!
},
delegate(PlayerIOError error) {
//Error authenticating.
}
);
vikreed
 
Posts: 23
Joined: September 30th, 2017, 8:02 am

Re: Option to Save PlayerIO access tokens

Postby vikreed » January 2nd, 2018, 6:48 am

But what my Point was, irrespective of the authentication method, we should be able to somehow save the state of CLIENT (class) at device or browser.
And the next time when we log in, Client class should be repopulated to the previously stored state, hence we will have no need to Authenticate.

We can also have an Expiry date to this access token (maybe 60 days as Facebook or 90 days). Every time we log in, we can check if expiry is near or the access token has expired then only we will go for Re-Authentication.
vikreed
 
Posts: 23
Joined: September 30th, 2017, 8:02 am

Re: Option to Save PlayerIO access tokens

Postby Henrik » January 2nd, 2018, 7:36 am

I see your point.

There's a bunch of security considerations mostly, we'll give it some thought.

Being able to serialize a connected Client is a separate issue, although it relies on longer-lived session keys. I guess you would save having to reload a player's Vault and PlayerObject, etc. We haven't built any of the clients with that in mind though, so it would take considerable effort to get it done. But I can definitely see how useful it would.


An immediate way of solving your issues though is to move all the Client authentication and refreshes to the background while your app is starting up or resuming. If you can distract the player with choices that don't look like the app is actually waiting for things, that's a pretty good strategy.
Henrik
.IO
 
Posts: 1827
Joined: January 4th, 2010, 1:53 pm

Re: Option to Save PlayerIO access tokens

Postby vikreed » January 2nd, 2018, 7:57 am

yeah, we have thought about workarounds, but what we have realized in our beta testing is that the market is getting very choosy. Players many times, just want to have a quick match for a min or two. They really don't want a lot of loading time. We are trying to save every second here.

With this change, we can surely save 4-5 seconds. As we use basic Authentication, Our first step is to generate an Auth Code and we generate a Secured Auth Code for the player(based on user id) on Server(some other server) and then use Authenticate(with user id and Auth code) to log in to player IO. So this becomes a 4-5 second job overall.

Regards,
Vikreed Team
vikreed
 
Posts: 23
Joined: September 30th, 2017, 8:02 am


Return to QuickConnect