oracle / cordova-plugin-wkwebview-file-xhr

Cordova Plugin for WebView File XHR
Universal Permissive License v1.0
138 stars 118 forks source link

Does not seem to work with AWS Javascript SDK for S3 #58

Closed adamjpeterson closed 4 years ago

adamjpeterson commented 4 years ago

Prior to installing cordova-plugin-wkwebview-engine and cordova-plugin-wkwebview-file-xhr I was able to upload blobs to AWS via their javascript S3 SDK. Now when running the exact same code, the AWS sdk errors out with "null" and no real information.

Here is my code (given a path, bucket_name, file blob, and configured AWS) var file_name = encodeURIComponent(path.substr(path.lastIndexOf('/')+1)); var params = { Bucket: bucket_name, Key: file_name, ContentType: file.type, Body: file}; var upload = new AWS.S3.ManagedUpload({params: params}); upload.on('httpUploadProgress', function(progressEvent) { //progress bar stuff }).send(function(err, data) { if(err){ console.log(err); //<- shows null } else{ //upload success } }); }

Response from AWS: [Log] Error: null (cordova.js, line 1540) extractError — aws-sdk-2.712.0.min.js:9615:203 callListeners — aws-sdk-2.712.0.min.js:2363 emit — aws-sdk-2.712.0.min.js:2350 emitEvent — aws-sdk-2.712.0.min.js:1576:184 e — aws-sdk-2.712.0.min.js:1453 (anonymous function) — aws-sdk-2.712.0.min.js:1642 (anonymous function) — aws-sdk-2.712.0.min.js:1654 (anonymous function) — aws-sdk-2.712.0.min.js:1462 (anonymous function) — aws-sdk-2.712.0.min.js:1577 callListeners — aws-sdk-2.712.0.min.js:2370 emit — aws-sdk-2.712.0.min.js:2350 emitEvent — aws-sdk-2.712.0.min.js:1576:184 e — aws-sdk-2.712.0.min.js:1453 (anonymous function) — aws-sdk-2.712.0.min.js:1642 (anonymous function) — aws-sdk-2.712.0.min.js:1654 (anonymous function) — aws-sdk-2.712.0.min.js:1462 (anonymous function) — aws-sdk-2.712.0.min.js:1577 callListeners — aws-sdk-2.712.0.min.js:2370 o — aws-sdk-2.712.0.min.js:2356 (anonymous function) — aws-sdk-2.712.0.min.js:2139 (anonymous function) — aws-sdk-2.712.0.min.js:8240 finishRequest — aws-sdk-2.712.0.min.js:6942 (anonymous function) — aws-sdk-2.712.0.min.js:6891:268 (anonymous function) — xhr-polyfill.js:1203 (anonymous function) — xhr-polyfill.js:997 [native code] (anonymous function) — xhr-polyfill.js:661 [native code] promiseReactionJob

Any help would be appreciated!

adamjpeterson commented 4 years ago

A follow up: while I was never able to get any of the AWS javascript SDKs to work, I found a workaround. I was able to use XHR and post directly to S3. More info can be found here: https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-UsingHTTPPOST.html. This SO convo (and the links within the question and answer) were very helpful: https://stackoverflow.com/questions/16276244/use-aws-s3-success-action-redirect-policy-with-xhr

manish2788 commented 4 years ago

Hi @adamjpeterson , We are working on validating certain behaviors of this plugin. We will revert with the updates soon.

manish2788 commented 4 years ago

Hi Adam (@adamjpeterson ), Can you provide me sample app which allows me to reproduce the issue reported by you.

adamjpeterson commented 4 years ago

Hi @manish2788 I'm not sure I can. Apple won't approve any app that is not WkWebView, I'm now realizing I'm running into size limits with the post directly to s3 so it's not yet a solution that will work, and I can't release breaking code (our app on UIWebView works great with the AWS javascript SDK). At the moment I'm kind of stuck until I can figure this out. Am open to ideas.

timkellypa commented 4 years ago

My team had a similar issue. I believe the problem is that in xhr-polyfill.js, HEADERS_RECEIVED is spelled incorrectly (HEADERS_RECIEVED). After changing it, things appeared to work.

AWS seems to attempt to monitor that state, but it fails the check, since the const is spelled incorrectly.

It appears that there is already a pull request for this issue. You could try this. https://github.com/oracle/cordova-plugin-wkwebview-file-xhr/pull/37

adamjpeterson commented 4 years ago

That was it! Wow. Not getting those hours back :).

FYI the httpUploadProgress event doesn't fire. But it looks like that's a separate, documented issue here.