authtoken - session login

[borgb]

I took a look at the cloud.lua file to try and figure out what happens when you do a session login. And from what I can see the only thing that gets done is that cloudCore.authToken = params.authToken. So, you are in fact logged in after a session login. I tried just calling: cloud.getProfile() and it worked. The problem I had was that I am checkin if cloud.isLoggedIn, and that returns false.

So the issue I am having with session login is that there is no feedback that you are infact logged in.  the cloudCore.isLoggedIn never gets set when doing session login, because only facebook and user login seem to make any calls here:

    if params.type == “facebook” or params.type == “user” then

        _postCC( path, pathParams, networkListener )

    end

Not sure if this is right or not, just what I think might be the issue. Someone with more knowledge could maybe look it up

[rob]

Here is the way this works. Al cloud API calls that require the app to be logged in uses this auth token as a hidden parameter in all their calls. You don’t have to pass it to multiplayer.getMoves for instance. If you are not logged in, you login via email or Facebook and the cloud provides you an auth token. From the clouds perspective that token is good forever and you never have to login again if your app doesn’t exit (crash, killed by user, exit button on android, etc.) If you save the auth token and if you start up, you call the session based login. It does not reachi out to the server or do anything more than making the auth token available to the API calls like you never left. So there won’t be any call to the auth listener. If you have a valid auth token and once you set it, you are good to go. Hope this helps. Rob

[schizoid2k]

Hi Rob,

Thanks for the clarification.  It does help, and I appreciate the reply.

I guess what was confusing to everyone is that the documentation states that a cloud.login call with the “session” parameter will return a “sessionLoggedIn” event to the listener, and that is not happening… although I do understand why now.

In my listener, I set a lot of variables based on a successful login, but based on your latest message, I guess the method that will work is to set cloud.authToken with the saved token, and to assume that login is successful, therefore set the variables I need to set.

I have confirmed that setting authToken does in fact return achievement and leaderboard details when called.

[borgb]

its like schizod2k says, we expected it to return some kind of info or a confirmation that you had been logged in with the authtoken as described in the guide. You should remove this so others dont get confused by this as well.

so instead of using cloud.isLoggedIn I now have to figure out a different way to at least check for online connection before logging in and notifying the user that he needs to check his device connection if its off. Just logging in and assuming everything is fine like with authtoken is not an option. There are devices out there that isnt always online and the user must be notified else they just get mad and shout broken app and give you one star ratings

[rob]

@schizoid2k, that’s probably my fault, when I wrote the guide.  I missed it.  I’ll see if we can get that revised.

@borgb, there are plenty of ways of checking for a network connection without depending on the cloud’s login.  But if you think you’re logged in, you could hit one of the API’s like getting the users profile and see if that returns and error or not.

[schizoid2k]

Thanks Rob… Your last comment also gives me an idea as well… We can check for connectivity by calling a cloud function to see if there is an error. That’s a workable solution for me.

[borgb]

I am using the code from aukStudios here to check for internet connection:

http://forums.coronalabs.com/topic/33356-check-for-internet-connection/?hl=%2Bdevice+%2Bconnection#entry172766

works like a charm

Now onto tackling the matchmaking part of corona cloud

[Joel_DGS]

@schizoid2k

I guess what was confusing to everyone is that the documentation states that a cloud.login call with the “session” parameter will return a “sessionLoggedIn” event to the listener, and that is not happening… although I do understand why now.

@rob

@schizoid2k, that’s probably my fault, when I wrote the guide.  I missed it.  I’ll see if we can get that revised.

Hi! We also had this problem.

If you look at the cloud.lua code:

elseif params.type == "session" then if nil ~= params.authToken then cloudCore.authToken = params.authToken end eventType = "sessionLoggedIn" end

At some point there was an intention to generate an event, and frankly I don’t see why not. At least for consistency and if nothing else for conforming to the documentation.

[Joel_DGS]

@schizoid2k

I guess what was confusing to everyone is that the documentation states that a cloud.login call with the “session” parameter will return a “sessionLoggedIn” event to the listener, and that is not happening… although I do understand why now.

@rob

@schizoid2k, that’s probably my fault, when I wrote the guide.  I missed it.  I’ll see if we can get that revised.

Hi! We also had this problem.

If you look at the cloud.lua code:

elseif params.type == "session" then if nil ~= params.authToken then cloudCore.authToken = params.authToken end eventType = "sessionLoggedIn" end

At some point there was an intention to generate an event, and frankly I don’t see why not. At least for consistency and if nothing else for conforming to the documentation.