Uppy: AWS3 MultiPartUpload without Companion

Created on 7 Dec 2018  Â·  8Comments  Â·  Source: transloadit/uppy

I'm a bit confused about the structure of AWS + presigned url's + MultiPartUploads.

Is it possible to use this without Companion? The documentation states that you can provide your own presigned url through prepareUploadPart();

I've created my own PHP endpoint which uses the AWS SDK to create a signed url for this. In this case, is it still required to provide a Companion server url for the serverUrl option?

Thanks

AWS S3

Most helpful comment

You have two options:

One is to override the five functions, and make requests to your PHP endpoints yourself (e.g. using window.fetch). In that case you don't need to provide companionUrl, as Uppy only needs it when making the requests. In fact, in the codebase you can see Uppy asserting that companionUrl is provided at the beginning of the default implementations of each of these five methods.

The other option is to implement your PHP endpoints to match exactly the Node endpoints in the Companion – same URL, same request parameters, same response format. This is what I've done in uppy-s3_multipart, my Ruby port of the AwsS3Multipart endpoints. If these endpoints are defined in your main app, you can then just set companionUrl to '/', and that will make Uppy hit the following endpoints:

POST   /s3/multipart
GET    /s3/multipart/:uploadId
GET    /s3/multipart/:uploadId/:partNumber
POST   /s3/multipart/:uploadId/complete
DELETE /s3/multipart/:uploadId

So your PHP endpoints can be defined on these URLs. I find this approach much more convenient, as there is no additional JavaScript code I need to write. Uppy doesn't care whether these endpoints are implemented by the Companion or your PHP app, as long as they exist, accept the same request parameters and return same response data.

The Companion endpoints can be found here, they are very simple and nicely documented. https://github.com/transloadit/uppy/blob/fffd8ce4d8bac984eec8de5481d5a9bc795dd843/packages/%40uppy/companion/src/server/controllers/s3.js#L58-L278

All 8 comments

You have two options:

One is to override the five functions, and make requests to your PHP endpoints yourself (e.g. using window.fetch). In that case you don't need to provide companionUrl, as Uppy only needs it when making the requests. In fact, in the codebase you can see Uppy asserting that companionUrl is provided at the beginning of the default implementations of each of these five methods.

The other option is to implement your PHP endpoints to match exactly the Node endpoints in the Companion – same URL, same request parameters, same response format. This is what I've done in uppy-s3_multipart, my Ruby port of the AwsS3Multipart endpoints. If these endpoints are defined in your main app, you can then just set companionUrl to '/', and that will make Uppy hit the following endpoints:

POST   /s3/multipart
GET    /s3/multipart/:uploadId
GET    /s3/multipart/:uploadId/:partNumber
POST   /s3/multipart/:uploadId/complete
DELETE /s3/multipart/:uploadId

So your PHP endpoints can be defined on these URLs. I find this approach much more convenient, as there is no additional JavaScript code I need to write. Uppy doesn't care whether these endpoints are implemented by the Companion or your PHP app, as long as they exist, accept the same request parameters and return same response data.

The Companion endpoints can be found here, they are very simple and nicely documented. https://github.com/transloadit/uppy/blob/fffd8ce4d8bac984eec8de5481d5a9bc795dd843/packages/%40uppy/companion/src/server/controllers/s3.js#L58-L278

I think @stoopman and I have the same goal. We shall see. I arrived here in my journey to understand if I can use the Uppy client to perform AWS S3 Multipart uploading directly--that is, without a proxy. It seems that using an S3 pre-signed URL, the browser should be able to interact _directly_ with the S3 bucket.

Like @stoopman, my plan is that my custom app will have an API that use the AWS SDK to generate a temporary pre-signed URL for uploading a specific item. In my rainbow vision, the Uppy browser client would use this URL to do the multipart upload magic.

In fact, the first sentence of the documentation suggests this is exactly how this can be used:

The @uppy/aws-s3-multipart plugin can be used to upload files directly to an S3 bucket using S3’s Multipart upload strategy.

However, I can see how Uppy modifies the URL--suggesting it is designed to work only with the Companion server (or your own proxy designed with same interface).

:coffee:

@TroyWolf

However, I can see how Uppy modifies the URL

I'm not sure what this is referring to; the @uppy/aws-s3-multipart plugin definitely uploads directy to S3, but they do involve some S3 API calls to set up and complete the upload. The S3 URLs to upload to must also be signed, so Uppy has to somehow get signed URLs dynamically. By default it uses Companion for that, but you can write custom implementations for use with your own server. The uploads aren't proxied, but the API requests are, because you probably don't want to have your users be able to read your AWS secret keys (unless you use those keys that were intended for that, but I personally don't know how that works).

I think @janko gave an excellent answer to the original question so I'll close this issue!

having this error in uppy companion s3 multipart { error: "s3: filename returned from getKey must be a string" }

@mamoyko if you are still experiencing this, please let us know at the Community Forum, since this thread is about something else!

@stoopman were you able to complete/do this? I am trying to do the same and so far have not succeded. Do you have a working example that I can customize for my need? Thanks a lot in advance,

@russellanam no I went with the solution @janko provided. A proxy less integration is not possible as far as I know

@stoopman Thanks for replying.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

rrjanbiah picture rrjanbiah  Â·  3Comments

oyeanuj picture oyeanuj  Â·  3Comments

skunkwerk picture skunkwerk  Â·  3Comments

ogtfaber picture ogtfaber  Â·  4Comments

NihadOb picture NihadOb  Â·  3Comments