You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The unauthorized reply to a PROPFIND is what normally triggers the refresh of the token on the client. However, if token expires before this op. is scheduled we don't have a way to refresh and recover the request that failed "Unauthorized".
Also, this works out for PROPFINDs since the client will "pool" again the WebDAV endpoint, but other request(s) need to be enqueued for later replay.
There are some places where this might lead to temporary, unexpected behavior. For now, the only place I've found to display this would be:
When setting up the account (on the last page of the wizard) just wait (1h default) for the expiration to happen and then, either:
Try to get the folder list (for selective sync)
Click on "Continue"
Other good candidates, I can think of, where this might happen:
Creating a share
Accepting/dismissing a notification
I'll try to determine if more of these scenarios can pop up so we could place a refresh switch on them cc/ @ogoffart
The text was updated successfully, but these errors were encountered:
@ogoffart yeah, the 20s expiration time was just a dirty trick used to force the behavior; but e.g. having the last wizard page open for more than 1h will cause this behavior with the default app state.
if the token expires during the sync, the sync will be stopped and restarted
This one is interesting; what about a large chunked upload? Could we wait for re-authentication and pick from the last chunk that failed? Trying to upload a large file with a flaky connection might result in constant failures due to token expires then.
The other day, I was doing some stress checks in the context of owncloud/core#30365 (comment). For that, I adjusted the time for access token expiration on https://github.com/owncloud/oauth2/blob/2f99ecafca7ba2ba1e557dd39d7917bb44ac05ff/lib/Db/AccessToken.php#L52-L57 with way shorter periods (~20s). This contributed to find a potential issue.
PROPFIND
is what normally triggers the refresh of the token on the client. However, if token expires before this op. is scheduled we don't have a way to refresh and recover the request that failed "Unauthorized".PROPFIND
s since the client will "pool" again the WebDAV endpoint, but other request(s) need to be enqueued for later replay.There are some places where this might lead to temporary, unexpected behavior. For now, the only place I've found to display this would be:
Other good candidates, I can think of, where this might happen:
I'll try to determine if more of these scenarios can pop up so we could place a refresh switch on them cc/ @ogoffart
The text was updated successfully, but these errors were encountered: