Skip to content
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

Parse Sabre Exception in OC.Files.Client and file-upload #6079

Merged
merged 1 commit into from
Dec 11, 2017

Conversation

LukasReschke
Copy link
Member

@LukasReschke LukasReschke commented Aug 11, 2017

In case of error, instead of a generic error message, an upload will
display whichever message is returned in the Sabre Exception, if
applicable.

To test this enable the antivirus app and upload a EICAR test virus file or so.

Ref owncloud/core#28620

@MorrisJobke
Copy link
Member

@danxuliu Mind to help reviewing this one?

Copy link
Member

@danxuliu danxuliu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that it would be better to add chunked uploads first and, then, add this parsing of Sabre exceptions.

@@ -900,6 +916,7 @@ OC.Uploader.prototype = _.extend({
status = upload.getResponseStatus();
}
self.log('fail', e, upload);
self._hideProgressBar();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When several files are uploaded at once and one of them fails this hides the progress bar before those coming after the failed one have finished. Moreover, this should not be needed anyway, as the progres bar is only shown in the fileuploadstart event, so the current _hideProgressBar call in the fileuploadstop event should always hide it when there are no more files being uploaded, even in case of failures (in fact, the current call to _hideProgressBar when the upload is aborted is not strictly needed, as the fileuploadstop event will be eventually triggered, but in that case it does not harm to call it there as the pending uploads will be aborted too).

Having said that... they had to have a reason to add a call to _hideProgressBar in fail in ownCloud, so maybe I am missing something. Thus I would left it as is in this pull request and remove it in a different one so if the progress bar happens to not be hidden in some cases then the problem can be bisected to that removed call.

var message = '';
if (upload) {
var response = upload.getResponse();
message = response.message;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be ensured that response is not undefined before using it, as there is at least one (obscure...) code path in which getResponse can return undefined: when a chunked upload fails to create the temporary directory before uploading the file itself the upload is aborted even before it was started, so in the end this causes fail to be called with an upload without a response. Chunked uploads do not work right now anyway, but just checking the object before using it makes no harm, and there could be other code paths that I have not found but need it too.

Also note that if the response is checked before being used, when a chunked upload fails to create the temporary directory before uploading the file itself just a message that reads abort is shown, but that is a different matter.

@@ -1105,6 +1127,19 @@ OC.Uploader.prototype = _.extend({
var upload = self.getUpload(data);
upload.done().then(function() {
self.trigger('done', e, upload);
}).fail(function(status, response) {
var message = response.message;
self._hideProgressBar();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above; if several files are loaded at once and the upload of the first one fails when moving the temporal assembled file of a chunked upload to its final location the progress bar would be hidden even if there are other files being uploaded.

In any case, the additions in fileuploaddone do not really belong to this commit/pull request. They are error handling code for chunked uploads (which seems to be done separately from other error handling because it handles failures in the movement of the temporal assembled file to its final destination, which is outside the standard flow of upload failures), but currently chunked uploads do not work at all (because as far as I know it should use the v2 DAV backend to use the Upload collection in the backend, and currently it uses the v1).

@MorrisJobke MorrisJobke added 2. developing Work in progress and removed 3. to review Waiting for reviews labels Oct 27, 2017
@MorrisJobke
Copy link
Member

I think that it would be better to add chunked uploads first and, then, add this parsing of Sabre exceptions.

@danxuliu Are you open to do that?

@danxuliu
Copy link
Member

@MorrisJobke

I think that it would be better to add chunked uploads first and, then, add this parsing of Sabre exceptions.

@danxuliu Are you open to do that?

Yes, I have been working on it for quite some time now, but it is taking me way longer than expected :-S I hope to finish it soon, though ;-)

@codecov
Copy link

codecov bot commented Nov 10, 2017

Codecov Report

Merging #6079 into master will increase coverage by 0.01%.
The diff coverage is 92.59%.

@@             Coverage Diff              @@
##             master    #6079      +/-   ##
============================================
+ Coverage     50.74%   50.76%   +0.01%     
  Complexity    24479    24479              
============================================
  Files          1581     1581              
  Lines         93578    93595      +17     
  Branches       1353     1355       +2     
============================================
+ Hits          47487    47509      +22     
+ Misses        46091    46086       -5
Impacted Files Coverage Δ Complexity Δ
core/js/files/client.js 83.57% <92.59%> (+0.55%) 0 <0> (ø) ⬇️
lib/private/Security/CertificateManager.php 91.08% <0%> (-1%) 39% <0%> (ø)
lib/private/Server.php 83.41% <0%> (+0.12%) 125% <0%> (ø) ⬇️
core/js/js.js 63.55% <0%> (+0.56%) 0% <0%> (ø) ⬇️
lib/private/Files/Cache/Propagator.php 96.2% <0%> (+1.26%) 16% <0%> (ø) ⬇️

@danxuliu danxuliu added 3. to review Waiting for reviews and removed 2. developing Work in progress labels Nov 10, 2017
@danxuliu
Copy link
Member

Now that chunked uploads have been merged I have imported again this pull request from ownCloud onto current master.

Note that I have just imported the original pull request, and I have not addressed yet my own comments; I will do that later in other pull requests.

In case of error, instead of a generic error message, an upload will
display whichever message is returned in the Sabre Exception, if
applicable.

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
@danxuliu
Copy link
Member

Oops, I forgot to sign the commit. Fixed now ;-)

@MorrisJobke
Copy link
Member

@danxuliu Should we try to get this in 13 or is 14 fine?

@danxuliu
Copy link
Member

danxuliu commented Dec 8, 2017

@MorrisJobke 13, please; I "need" this merged to import more fixes for chunked uploads in Web UI.

@MorrisJobke MorrisJobke mentioned this pull request Dec 8, 2017
28 tasks
@MorrisJobke
Copy link
Member

@MorrisJobke 13, please; I "need" this merged to import more fixes for chunked uploads in Web UI.

As far as I can see, this is ready for review, right?

@danxuliu
Copy link
Member

@MorrisJobke

As far as I can see, this is ready for review, right?

Right :-)

@blizzz
Copy link
Member

blizzz commented Dec 11, 2017

@danxuliu are they points you have had your remarks on resolved? Or are they as a note? then we should turn them into issues (after merge)?

@danxuliu
Copy link
Member

@blizzz

are they points you have had your remarks on resolved? Or are they as a note? then we should turn them into issues (after merge)?

They are not solved in this pull request, but there is no need to fill issues about them, as I am already working on fixing them.

Copy link
Member

@MorrisJobke MorrisJobke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested and works 👍 Code makes sense

@MorrisJobke
Copy link
Member

How to test:

  • for example add throw new BadRequest('Some problem'); to the beginning of public function put($data) { in apps/dav/lib/Connector/Sabre/File.php

Copy link
Member

@blizzz blizzz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tested with files_accesscontrol, also working

@blizzz blizzz merged commit 4fc8984 into master Dec 11, 2017
@blizzz blizzz deleted the fix-antivirus branch December 11, 2017 16:12
@tobiasKaminsky
Copy link
Member

tobiasKaminsky commented Feb 22, 2018

I assumed that a sane message would also shown on android, but we get "unsupported media type".
This returned by the server.

Ref: nextcloud/android#1391

@tobiasKaminsky
Copy link
Member

@rullzer please see above. Do you recall if you fixed this with latest antivirus update?

@rullzer
Copy link
Member

rullzer commented Mar 13, 2018

yes the server throws an unsupported media type... but with a message as far as I can tell

@tobiasKaminsky
Copy link
Member

Aha. This is probably the problem then, as we do not use the message, but only the main name.

@tobiasKaminsky
Copy link
Member

tobiasKaminsky commented Mar 15, 2018

@rullzer would it be possible to have a more meaningful throwable, like "virus detected", this way we could use it better on android.
Or is this the only occurrence where "unsupported media type" is used?

@rullzer
Copy link
Member

rullzer commented Mar 15, 2018

We can't really do that. The app has to throw an exception that the server has predefined. Creating specialized exceptions for each app is not really scaleable.

Can't you just pass on the message (it should be translated anyways)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3. to review Waiting for reviews bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants