This is so strange, to get the session to actually work I had to call <?php session_start(); ?> on the first line of code and now it is showing correctly.
oops, sorry I forgot that. So you are seeing the data now?
Yes, here it is with a few question marks added in for security, waiting for it to expire in 32 minutes so i can see what it does.
Array ( [GoogleOAuthProvider_access_token] => ya29.a0Ae4lvC3???????????HRioQrkGVSYqGVmxvqD5L9aFU12BPKTTpGMf6rZY_GzmEhrOmppXby6Pr4J5qtHtlWJjxFGcKgVHM_K4CzScRo9kP5m29MceskE1F8IamqIAVSF7O8e6Q0gwrx8gR58ft2w [GoogleOAuthProvider_expires] => 1586134342 [GoogleOAuthProvider_refresh_token] => 1//03URs9h-RYZ4zCgYIARAAGAMSNwF-L9IrT4H???????????_NQdz2ozmJpMAkpLwtUylBTueuVdRjEfXfiHRjK1Y)
I would check to see if it’s still in Session storage before the expiry time. Just to make sure the server isn’t destroying it beforehand.
Its a bit odd but I do not see the session under Session Storage or anywhere else in the Application tab of Google.
It’s using the server session storage. Browser storage is different and not being used.
If you refresh the page you put the php code on is the data still there?
Yes, on refresh it remains
If it’s staying all the way up until the expiry time, then I’m guessing Wappler is not running the job to refresh the access token.
And now it works, literally the only change made is adding the
<?php
// Start the session
session_start();
// Show session variables
print_r($_SESSION);
?>
added to the top of the page, as well as removing the dmx-on:unauthorized="browser1.goto('index.php')" so I really have no clue why.
But i watched it switch from one access token to another and the expiry time change.
Working exactly like i wanted it from 7 days ago, haha.
I am going to add back the redirect on unauthorised, as maybe that is redirecting the browser even though a new token is being sent.
The session stuff was just for us to see the data. I would remove that as I don’t think it would have any affect on it working.
The issue is probably related to your unauthorized code redirect – although I would not expect that to stop the refresh process.
1 Like
Yeah, I would imagine there is already a time delay so the session does not expire and then do the refresh, but I am adding back the unauthorised code to see what happens. I suppose we will know in just a moment.
Expires at 03:52:23 GMT+2
Well done Keith, i think you have figured it out, the on:unauthorised event is starting the re authentication procedure at the exact same second that the refresh token is pulling a new access token, so if I manually navigate back to the other page, it has a new access token already.
Wonder if its a bug or the way it is meant to work.
1 Like
Similarly to how you check for an error in the flow, is there a way to do this purely in server connect, so when the API gives an error like this
{"error":{"errors":[{"domain":"global","reason":"authError","message":"Invalid Credentials","locationType":"header","location":"Authorization"}],"code":401,"message":"Invalid Credentials"}}
Then i can do something in that event?
Hi Patrick, can you comment how long the session lasts? I am using a different provider that requires token refresh in same manner as Google. I am doing this with NodeJs / Cordova / IOS will it be ok to handle this just by the session or something else I need to configure?
Is there any downside/benefit from using either self maintain or session?
Sessions are normally configured in your web server, normally the session is deleted after about 20 minutes of inactivity. Also in most cases sessions are lost after you close the browser because in most cases the session id is stored in a cookie that gets deleted on close of the browser.
Access tokens also expire, there are access token that expire after a few minutes while others will be usable for days or will not expire. When an access token is expired then you will need the refresh token to ask for a new access token.
If you only use the oauth as social login then you don’t have to keep the tokens, but if you want to access the api in name of the user and don’t want to ask the user to authenticate each time then you should store the tokens in your database for reuse.
2 Likes