-
Notifications
You must be signed in to change notification settings - Fork 186
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
Single big file upload with desktop-client fails if OIDC token expires #1205
Comments
Jörn Friedrich Dreyer commented: us tus enabled or not? if tus is disabled ... there is not much we can do ... other than the old chunking algorithms ... newchunking should be able to list the progress as well. v1 I'm not sure |
Michael Stingl commented: No TUS upload in the mitmproxy. Please provide new mitmproxy flows, or test setup. |
Ilja Neumann commented: Same behaviour with disabled token-cache in the proxy |
Ilja Neumann commented: Setup with docker-compose to local lan-ip docker network create -o "com.docker.network.bridge.host_binding_ipv4"="192.168.0.33" bridge2 #use your lan ip Modify ocis/deployments ocis_traefik example like so: https://gist.github.com/IljaN/413833ad66c4f29f3cdc444f5a022bb2 Add to /etc/hosts: 192.168.0.33 ocis.owncloud.remote #your lan ip mitmproxy -k -p 9999 Start sync-client with proxy to localhost:9999 and throttle the connection to 150 Connect to ocis.owncloud.remote Create large file: Upload is restarted after 401 and never finishes. |
Michael Barz commented: please check status |
@IljaN simplify the setup? Why do we need the desktop client? Reproduce with |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions. |
@IljaN on which version did you test this in jan? |
Could be fixed by #2188 |
Needs to be tested during #2197 |
Currently, big file uploads fail because of expiration of the token after 10m. Until this is fixed (see owncloud/ocis#1205), we can just increase the expiration time to 24h.
Still fails if upload takes longer than the token lifetime
|
If the Desktop client is already using TUS, there would no need to abort the upload of the file because it is not authenticated via the OIDC token but by the TUS upload token (valid for ~ 1 week) |
Please always report exact client version: TUS requires 2.9 daily builds: Please enable HTTP logging for your tests: or
More information: |
@michaelstingl here is the log of one sync run |
Strange, it says 2.8.2, but it tries TUS. Could you post the version information from the settings windows?
Also strange, log doesn't contain a response for this request? ( |
@felix-schwarz could you try to upload a 2GB file from iOS and post the related log? (http, timing etc) |
@michaelstingl Uploading a 2 GB file in a single request over the course of 42 minutes results in a Request:
Response:
Interestingly, |
The oCIS log to @felix-schwarz problem:
|
@michaelstingl the log of ownCloud-2.9.0-daily20210723.4714: I didn't see any progress during the sync run: But there was network ingress on the oCIS instance. |
That looks like ocis waits for the complete request to arrive before - internally - handing it down to the tus backend. At which point the token has expired and the upload fails. |
You're right, we need to investigate in this |
Upload maximum duration for TUS uploads is hard coded to 10 minutes |
ok, make it configurable, the 10 min default is not good. We need to check other places. Requirement from PM is "NEVER introduce ridicolous timeouts" 😄 |
I got it wrong on Friday... The token is valid for 864000 minutes, since we set it in oCIS to a higher value. I will continue to investigate EDIT: ocis/storage/pkg/flagset/gateway.go Lines 31 to 37 in 85550a3
and https://github.com/cs3org/reva/pull/1924/files |
I noticed similar issues on my setup when uploading a larger file (~2GB) and also saw similar error messages, especially the
the issue seemed to be gone. |
Thanks for digging into this :-) There are dedicated up- and download tokens, which are valid for a much longer timespan and they should be sufficient in that case. But somewhere seems to be a codepath for uploads which still uses the core access token (even if it shouldn't from my understanding) |
Possible fix: cs3org/reva#1941 |
After cs3org/reva#2151 clients shouldn't get a 500 anymore after a successful upload, despite the token being expired. They should then get a 200 but without the file information. These can be obtained by an propfind. The Desktop client handles this correctly. |
Current situation (oCIS 1.13.0):
|
This approach? tus/tus-resumable-upload-protocol#93 |
No :-( It's in the capabilities ->
I'm not sure where to plan / schedule thinks like contributing to the TUS protocol. But I think it would be a benefit for all to have it in TUS itself even if the discussion looks quite dead. @dragotin @micbar Is that something for an oCIS sprint? |
The issue seems to be that the upload aborts after KONNECTD_ACCESS_TOKEN_EXPIRATION which defaults to 10 minutes.
Latest desktop sync-client testpilot daily.
fallocate -l 4G 4G.bin
inside the clients data-dirClient logs => This probably leads to the sync-abort as the request is (probably?) done with an expired token.
See attached mitmproxy log
Server logs:
The text was updated successfully, but these errors were encountered: