Checking the order things happen, I noticed that the persistent token is deleted before the new one is confirmed.
By doing it, if something goes wrong when the new token is requested (like a connection timeout or something), you won't be able to try to get the new token anymore, unless you authenticate in the browser again.
Imagine this scenario:
Token is expired
You delete the current token (line 210)
You call $this->requestNewAccessToken(); (line 213)
Something goes wrong in step 3
You don't have the persistent token anymore, so you don't have the refresh token and you are stuck
I'm not sure if deleting the old token is really necessary for other types of token persistence, but talking about FileTokenPersistence, I don't think it is, since the new token will override the old one.
Hmm, good point. I think it would be useful to keep the old token around until after confirmation of the new token on other providers as well, since it may contain other useful information, like the refresh token.
https://github.com/kamermans/guzzle-oauth2-subscriber/blob/2276afd2b34917e2f75912ac129fc8b2ebfc9b82/src/OAuth2Handler.php#L210
Hi there!
Checking the order things happen, I noticed that the persistent token is deleted before the new one is confirmed. By doing it, if something goes wrong when the new token is requested (like a connection timeout or something), you won't be able to try to get the new token anymore, unless you authenticate in the browser again.
Imagine this scenario:
$this->requestNewAccessToken();
(line 213)I'm not sure if deleting the old token is really necessary for other types of token persistence, but talking about FileTokenPersistence, I don't think it is, since the new token will override the old one.