Maylo99
December 14, 2024, 11:28am
1
Hi, I’m trying to implement direct uploads to a DigitalOcean bucket. The direct uploads work just fine, and I can see the file uploaded in the bucket. However, after the upload, I get these errors:
I can see both the ETag and Location headers listed in the response headers, but I don’t know why I’m getting these errors in the console. I’ve been struggling with this for whole day, trying to figure it out.
This is what my CORSConfiguration looks like:
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
<AllowedOrigin>http://localhost:5000</AllowedOrigin>
<AllowedMethod>GET</AllowedMethod>
<AllowedMethod>POST</AllowedMethod>
<AllowedMethod>PUT</AllowedMethod>
<MaxAgeSeconds>3000</MaxAgeSeconds>
<AllowedHeader>Authorization</AllowedHeader>
<AllowedHeader>x-amz-date</AllowedHeader>
<AllowedHeader>x-amz-content-sha256</AllowedHeader>
<AllowedHeader>content-type</AllowedHeader>
<ExposeHeader>ETag</ExposeHeader>
<ExposeHeader>Location</ExposeHeader>
</CORSRule>
</CORSConfiguration>
This is my js controller that handles direct upload:
import {Uppy} from "@uppy/core";
import AwsS3 from "@uppy/aws-s3";
export default class extends Controller {
static targets = ["input", "preview", "hidden"];
connect() {
this.uppy = new Uppy({
autoProceed: true
});
this.uppy.use(AwsS3, {
endpoint: "/" // Shrine presigned URL endpoint
});
this.uppy.on("upload-success", (file, response) => {
// I cant reach this line I think is due to errors in console
console.log(file.name, response.uploadURL);
const uploadedFileData = JSON.stringify({
id: file.meta["key"].match(/^cache\/(.+)/)[1],
storage: "cache",
metadata: {
size: file.size,
filename: file.name,
mime_type: file.type
}
});
this.hiddenTarget.value = uploadedFileData;
// Display the uploaded image in the preview
this.previewTarget.src = URL.createObjectURL(file.data);
this.previewTarget.closest(".profile-logo__preview").classList.remove("d-none");
});
}
//this is executed when I select file
selectFile(event) {
const file = event.target.files[0];
if (file) {
this.uppy.addFile({
name: file.name,
type: file.type,
data: file
});
}
}
}
Versions:
“@uppy /aws-s3”: “^4.1.3”,
“@uppy /core”: “^4.3.0”,
Maybe I just forgot something to set up properly but I cant see any issue here…
Thanks for any help in advance.
Merlijn
December 16, 2024, 11:02am
2
Hi, could it be related to this?
opened 03:41PM - 02 Aug 24 UTC
closed 09:34AM - 11 Nov 24 UTC
Bug
### Initial checklist
- [X] I understand this is a bug report and questions sho… uld be posted in the [Community Forum](https://community.transloadit.com/)
- [X] I searched [issues](https://github.com/transloadit/uppy/issues?q=is%3Aissue) and couldn’t find anything (or linked relevant results below)
### Link to runnable example
_No response_
### Steps to reproduce
Using self hosted Companion and uppy-svelte, we used to use `upload-success` to get the path of the uploaded file to S3 from `result.body.key` which worked great using version 3. Now, after upgrading to v4.1 (and the companion to v5) and seeing that `upload-success` has changed such that we're supposed to be getting the path from `result.uploadURL`, we find that the `uploadURL` is always just set to the bucket's base URL without anything for the uploaded file itself.
Inspecting the networking traffic between browser and companion, we see that the response from companion has the filepath under `fields.key`. So it seems there's some mismatch between the latest companion and the latest client lib?
https://uppy.io/docs/uppy/#upload-success
### Expected behavior
`result.uploadURL` is the complete file's path on S3 (i.e. a `bucket-url/UUID-filename`)
### Actual behavior
`result.uploadURL` is just the bucket's URL
stv8
January 3, 2025, 6:05pm
4
Bumping that I am experiencing the same issue and the solution PR mentioned in the github issue did not fix it.
uploadUrl
is still just the base url for me, and there is not any “key” field under the meta
object.
Example
{
"response":
{
"body":
{
"location": "https://examplebukcet.fly.storage.tigris.dev/",
"content-length": "0",
"etag": "\"ea1517804e665b6bd2af7360873872da\"",
"ETag": "\"ea1517804e665b6bd2af7360873872da\""
},
"status": 200,
"uploadURL": "https://examplebukcet.fly.storage.tigris.dev/"
},
"file":
{
"source": "Dashboard",
"id": "uppy-rubymedina/custom/cdda1cf6f35cf6cd86f52da8c45fa69bce208716/jpeg-2v-1d-1e-image/jpeg-391645-1716254471825",
"name": "rubymedina_custom-cdda1cf6f35cf6cd86f52da8c45fa69bce208716.jpeg",
"extension": "jpeg",
"meta":
{
"relativePath": null,
"name": "rubymedina_custom-cdda1cf6f35cf6cd86f52da8c45fa69bce208716.jpeg",
"type": "image/jpeg"
},
"type": "image/jpeg",
"data":
{},
"progress":
{
"uploadStarted": 1735926729983,
"uploadComplete": false,
"bytesUploaded": 393471,
"bytesTotal": 391645,
"percentage": 100
},
"size": 391645,
"isGhost": false,
"isRemote": false,
"preview": "blob:http://localhost:3000/f842ca52-c955-42a4-b5ca-6dc60d8df599"
}
}
stv8
January 7, 2025, 6:31pm
5
I posted a relevant issue in the Github with my findings
opened 04:04PM - 04 Jan 25 UTC
Feature
### Initial checklist
- [X] I understand this is a feature request and questi… ons should be posted in the [Community Forum](https://community.transloadit.com/)
- [X] I searched [issues](https://github.com/transloadit/uppy/issues?q=is%3Aissue) and couldn’t find anything (or linked relevant results below)
`Uppy` Versions:
```
"@uppy/aws-s3": "^4.1.3",
"@uppy/core": "^4.3.1",
"@uppy/dashboard": "^4.1.3",
```
### Problem
TLDR; **Can we add the `key` from the presign response to the `file.meta` object?**
This issue is briefly mentioned in this related issue: https://github.com/transloadit/uppy/issues/5388
I am new to `uppy` and trying to integrate the `shrine` ruby library but encountering an issue where I can't retrieve the `key` used in the presign URL.
The shrine examples suggest reaching into the `file.meta.key` to retrieve the key used for the presign URL.
https://github.com/shrinerb/shrine/blob/1ce6da4be0ca62ecd5776f107fcd0d657b773f28/demo/assets/js/app.js#L86
```js
return JSON.stringify({
id: file.meta['key'].match(/^cache\/(.+)/)[1], // object key without prefix
storage: 'cache',
metadata: {
size: file.size,
filename: file.name,
mime_type: file.type,
}
})
```
However I think these are now outdated and in new versions of `uppy` it appears to suggest to use the `response.uploadURL` instead.
The `uploadURL` variable appears to be sourced via the `Location` header, however I'm not using `s3` but an `s3` compatible service (`Tigris`) which doesn't set the `Location` header.
This is causing problems because `shrine` cannot properly function without the `key` used for the upload.
Is there any way we could add the `fields`, which are returned in the call to the presign URL, back to the `meta` section of the file object?
For example, this is the response of the call to my presign endpoint
```json
{
"fields":
{
"key": "cache/95b0c3ae23204c43a636977fd52172c2.jpg", <---- can we add this to the `file.meta` key
"Content-Disposition": "inline; filename=\"filename.jpg\"; filename*=UTF-8''filename.jpg",
"Content-Type": "image/jpeg",
"policy": "$example_policy",
"x-amz-credential": "$credential",
"x-amz-algorithm": "AWS4-HMAC-SHA256",
"x-amz-date": "20250103T231102Z",
"x-amz-signature": "$signature"
},
"headers":
{},
"method": "post",
"url": "https://mybucket.fly.storage.tigris.dev"
}
```
and here is an example file object which is constructed after the upload
```json
{
"source": "Dashboard",
"id": "uppy-filename/jpeg-1e-image/jpeg-391645-1716254471825",
"name": "filename.jpeg",
"extension": "jpeg",
"meta": {
// could we add the `key` from the presign response here?
"relativePath": null,
"name": "filename.jpeg",
"type": "image/jpeg"
},
"type": "image/jpeg",
"data": {},
"progress": {
"percentage": 0,
"bytesUploaded": false,
"bytesTotal": 391645,
"uploadComplete": false,
"uploadStarted": null
},
"size": 391645,
"isGhost": false,
"isRemote": false
}
```
### Solution
Add the `key` field from the presign response to the `file.meta` object
### Alternatives
I am very new to this library and unaware of any alternatives, I am very open to other solutions.
Let me know what you think, thank you!