-
Notifications
You must be signed in to change notification settings - Fork 670
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OAuth2: Refresh the token without aborting the sync #6819
Conversation
I have been testing this by adding this in HttpCredential::fetchFromKeychain
This simulate an expiration of the access token every 10 second. Then one Making an automated test for this would be quite hard as this is in the HttpCredential class, and this class is currently not automatically tested/testable. (All our sync engine test are using fake credentials) |
// Ignore redirects and authentication failures. | ||
// This is handled by AbstractNetworkJob, so don't let this job error out in this case. | ||
bool ok = disconnect(reply(), &QNetworkReply::finished, this, &GETFileJob::slotReadyRead) | ||
&& disconnect(reply(), &QNetworkReply::readyRead, this, &GETFileJob::slotReadyRead); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This works because newReplyHook
reconnects the signals, right? Suggestion:
// Redirects and auth failures (oauth token renew) will end up restarting the job. We do not want to process
// further data from the initial request. newReplyHook() will reestablish signal connections for the follow-up
// request.
Also, what if there's a 401 that doesn't cause a new job to be spawned? Then finishedSignal()
wouldn't be emitted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I now changed GETFileJob::finished so this does not happen
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, that looks like it works. What do you think about adding the comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment updated
OAuth2 access token typically only has a token valid for 1 hour. Before this patch, when the token was timing out during the sync, the sync was aborted, and the ConnectionValidator was then requesting a new token, so the sync can be started over. If the discovery takes longer than the oauth2 validity, this means that the sync can never proceed, as it would be always restarted from scratch. With this patch, we try to transparently renew the OAuth2 token and restart the jobs that failed because the access token was invalid. Note that some changes were required in the GETFile job because it handled the error itself and so it was erroring the jobs before its too late. Issue #6814
@micbar Do you want to help us to test this in one the actual setups? |
I could send a patched client to the user with the issue. |
@micbar : I just merged the patch, which means that the 2.5.1 daily build from tomorrow will have the patch. They could try the daily build. |
Would be great. |
OAuth2 access token typically only has a token valid for 1 hour.
Before this patch, when the token was timing out during the sync, the
sync was aborted, and the ConnectionValidator was then requesting a new
token, so the sync can be started over.
If the discovery takes longer than the oauth2 validity, this means that
the sync can never proceed, as it would be always restarted from scratch.
With this patch, we try to transparently renew the OAuth2 token and restart
the jobs that failed because the access token was invalid.
Note that some changes were required in the GETFile job because it handled
the error itself and so it was erroring the jobs before its too late.
Issue #6814