Refresh token (Google)

The function CheckAccessToken() does not try to obtain a refresh token ?
Only the CallApi() manage refresh token.
Is it correct ?

I am not sure about this logic.
Because refreshing a token during a CallApi() will never fail ?

Otherwise, in case of failure, offline apps have to stop in middle of their process, because the need to spawn a browser authorization :-D)







For reference:
developers.google.com/identity/prot ...

The CheckAccessToken function will retrieve a refresh token if the API provides it. Some APIs just need you to specify extra parameters to return the refresh token.

For instance Google requires that. This class will pass those parameters if you set the offline variable to true.

If you have previously obtained a token and it expired, either CheckAccessToken and CallAPI will attempt to renew the token as long as the refresh token was obtain and preserved.

Read this article:

phpclasses.org/blog/package/7700/po ...

Thanks Manuel, I followed your tips in the blog.
Are there extra parameters, apart $client->offline?

Below I provide a step-by-step report on debuging oauth_client.php.

=== We are the 2-june 2015, at 20:20
The access token is saved (serialized) in a simple file.
(I used a class based on cookies_oauth_client class)
Everything works well
(except CheckAccessToken does not manage itself the refresh_token)

=== Debuging function CheckAcessToken($redirect_url)
IN file Oauth_client_php

=== Configuration of client class is:

$client->debug = true; // see below the server log

$client->offline = true;
$client->server = 'Google';
$client->redirect_uri = $CLIENT_REDIRECT; // 'http://' . $_SERVER['HTTP_HOST'] . '/index.php';
$client->client_id = $CLIENT_ID;
$client->client_secret = $CLIENT_SECRET;

$client->oauth_version="2.0"

=== Step by step debuging of CheckAccessToken

"
switch(intval($this->oauth_version))
{
case 1: // ignored

case 2:

if(!$this->RetrieveToken($valid))
return false;

===> LOG: [Tue Jun 02 20:20:24 2015] OAuth client: Checking if OAuth access token was already retrieved from https://accounts.google.com/o/oauth2/token
===> LOG: [Tue Jun 02 20:20:24 2015] OAuth client: The OAuth access token expired on 2015-06-02 00:26:51 UTC

===> (Watches) $client->access_token_expiry=2015-06-02 00:26:51
===> (Watches) $client->refresh_token= 1/YmnKahD9PNSgGNVRhv8K0WaI....

$expired =
(strlen($this->access_token_expiry)
&& strcmp($this->access_token_expiry, gmstrftime('%Y-%m-%d %H:%M:%S')) <= 0
&& strlen($this->refresh_token) === 0
);

===> $expired is ALWAYS FALSE when $this->refresh_token is set!
===> (IMHO, this seems like a "study case" you forgot to delete :-D)

if($valid
&& !$expired
)
return true;

===> The function always returns true if token_access exists, either current or expired !
===> Back to the browser, in debug mode, the OAuth_client displays, (current time is : 2015-06-02 20:20 UTC):

"
The application authorization was obtained successfully.
Access token: ya29.hQFLq....
Access token secret:

Access token expiry: 2015-06-02 00:26:51 UTC
"


=====================

To summarize:

In CheckAccessToken()
the $expiration is always false if the refresh_token is set,
whatever the expiration date.

For comparison, in RetrieveToken(&$valid)
the test on expiration works and the server log informs correctly about expiration.


I also tested to modify the expiry test and comment out the conflicting "&& strlen($this->refresh_token) === 0"
in function CheckAccessToken().

I can go ahead in code, but even in this case, only $redirect_url is set.
There is no attempt to refresh the code on CheckAccessToken().


Exploring the code, I see that refreshing the token is only done by CallApi().


=====


Well, client can work as is :)
But I am unsure of the logic and it seems that for oauth2, the refreshing is not implemented in CheckAccessToken()

Many thanks !

Yes, I found the issue. The cookie_oauth_client_class was not storing refresh tokens. It is fixed now. I just updated the class. Just let me know if you find other problems.

No, no change.

And the CheckAccessToken() function is unchanged in the Web

I downloaded the ZIP and in the Web is neither updated:
phpclasses.org/package/7700-PHP-Aut ...


The "conflicting" test is there (only this location uses this 3-conditions test) .:

============ Conflicting test, always return
$expired =
(strlen($this->access_token_expiry)
&& strcmp($this->access_token_expiry, gmstrftime('%Y-%m-%d %H:%M:%S')) <= 0
&& strlen($this->refresh_token) === 0);

if($valid && !$expired)
return true;

============
The 3rd condition implies that $expired is ALWAYS FALSE.
The only explanation for this condtion, I think, is because
you decided that refreshing tokens must be done only during
a CallApi(), and never during CheckAccessToken().

Not sure about the logic, but the class works this way.
(And it works well, indeed, except the surprise when CheckAccessReturn() returns a null link, while debug-Log tells the access_token is expired !!!)




I see you modified the ookie_oauth_client.php file.
You fixed the $session array to store/read the refresh token.

But I did already notice the missing lines and introduced myself the same patch before my tests
(In another thread, I lost a post with a report about how to convert cookie_oauth_client.php to storage_oauth_client.php)



Another remark is that in CheckAccessToken()
all the calls to Process2() use the syntax:
$this-Process2(null,false) ;

But as I understand, to be able to refresh a token, the call should be something like :
$this->Process2($code, $this->refresh_token)

Many thanks !

No, the fix was done on the cookie_oauth_client.php class file.

The problem was not where you think. It was on the fact that the cookie_oauth_client_class was not storing and retrieving refresh tokens. That is why the condition to renew the token was never true.

But I do NOT use the cookie_oauth_client_class :D)

=== Regarding "cookie_oauth_client" --
I do not use it. Sorry for this confusion :-D)

As I said, I made a copy, named it storage_oauth_client_class then modified GetAccessToken() StoreAccessToken() REsetAccessToken() and SetupSession() so they use a filename instead of a cookie,

And because I noticed that cookie_client_class did not store the refresh token, I introduced the same patch you haved done.
(I've described all these changes Sunday night, my post was lost and did not appear published -- I guess I forgot to click on "Submit" button :-))

Thus, the refresh token is perfectly stored.
Howevert, this refresh is only done via a call to CallApi().
But when using CheckAccessToken(), your class never call CallApi() because the 3-conditions test assumes the token is never expired.

===
/Closing this point about cookie_oauth_class.)

I continue on a following post.
Because I guess I know what's happening with the Google's specific refresh_token.

googlecode.blogspot.fr/2011/10/upco ...


Going again on

Well, I am not sure if it is working for you now.

The cookie_oauth_client_class is working now, so if you copied its changes, it should work for you too now.

OK, I created my first Post to Blogger using an offline refresh_token. In offline mode, there is no even need to test CheckAccessToken(). Only call directly CallApi(), and if something is wrong, then maybe the refresh-token is revoked.


The refresh_token is required to request a new access code to Google.
developers.google.com/identity/prot ...
"
Note that there are limits on the number of refresh tokens that will be issued; one limit per client/user combination, and another per user across all clients.
__You should save refresh tokens in long-term storage and continue to use them as long as they remain valid.__
If your application requests too many refresh tokens, it may run into these limits, in which case older refresh tokens will stop working.
"


=========== About the logic inside CheckAccessToken()

What is confusing, is the following:

-- Given: offline access, Oauth2, long-term storage of the refresh token (in a filename) then :


-- CheckAccessToken() returns a null $redirect_url even if the member { $client->access_token_expiry } is expired.

-- The renewal of the access_token is actually done when the server execute a CallApi(). Never inside CheckAccessToken().


The reason is because CheckAccessToken() ALWAYS return a null $redirect_url. In the code, the local variable $expiration is ALWAYS false.

As a result, an offline application that will use the oauth_class must do a CallApi() function to know that the access/refresh-token has been revoked by user, for example.

In the given context, any call CheckAccessToken() can be ignored ! :-)


I thinks this is logic problem.

A better logic of CheckAccessToken() function should be :

1) test if the stored access_token has expired ;

2) if expired, invoke Process2($code,true) to renew the access_code and expiration_time using the refresh_token ;

3) If the renewal fails, then set and return $redirect_url so the server knows that it need another User's online authorization (via a browser).


This way, and BEFORE to run any Google services (like Blogger), an offline application could test that the access_token and refresh_token available in long-term storage will work.

With the current configuration, for Google, Oauth2, in offline mode and with the refresh-token saved on disk, there is no reason to call CheckAccessToken().



Ok ? With more time, I could try to patch your class, but your work include Oauth1.0 and much more services than Google:-)

Well, maybe I could reduce it to a simple "blogger_oauth_client" for authors :-D




=======


Regarding our confusion about the cookie_oauth_client:

-- Yes the cookies_oauth_client.class did not stored the refresh-token. It was easy to fix, by comparison with the myslq_client

-- But I do NOT use the cookies_client.
It was simply a better model than the mysql client !

I created a derived class that stores the refresh-token in a file, by overriding the functions members GetAccessToken() a StoreAccessToken().
My class correctly stores and read the refresh-token.



Voilą !
Many, many thanks for this nice work.

Sorry for my approximate English and spelling, by the way,

And I am amazed to see that your class can work with so much services.

Just to correct my previous post:

the call to ChekAccessToken() is required because it calls GetAccessToken() and read the Access-token/Refresh-token from the storage.
If you do not call ChekAccessToken(), the CallAppi() would fail because it does not know the access_token for authorization.


Saying that, despite its name, ChekAccessToken() does not check the expiration or revokation of the access-token, and
we could simplify the call sequence as follow :

Initializs()
GetAccessToken(),
CallApi(.....)


;-D)

Best regards !
(And thanks again, your class saved me long days before able to understand Oauth, as a blogger that is both the Appi owner AND the Unique Authorized User !
True, Oauth may appear absolutely stupid under a blogger view: I have to _authorize_ myself to publish my onwn posts using my own appi !!

;-D))