Presigned S3 with content-type="application/octet-stream" is always 403 #1233
Comments
|
Hi! could you share a code sample that reproduces the problem? I tried uploading an extensionless file that was detected as |
|
Hi Renée, thanks for your response - below is a script I'm using. You'll
note that I'm not using a build process, but pulling from CDN - I'll put it
on my own server for production, but I want to avoid a build process for
web. Any help appreciated!
```js
function timestamp() {
var d = new Date();
var n = d.getTime();
return n;
}
var cookie = Cookies.get();
var uppy = Uppy.Core({
onBeforeFileAdded: (currentFile, files) => {
const modifiedFile = Object.assign({}, currentFile, {
name: currentFile.name.replace(" ", "-") //clean spaces
});
uppy.info(modifiedFile);
return modifiedFile;
}
})
.use(Uppy.Dashboard, {
inline: true,
target: "#drag-drop-area"
})
.use(Uppy.Webcam, {
target: Uppy.Dashboard,
modes: ["video-audio", "video-only", "audio-only", "picture"],
mirror: true,
facingMode: "environment"
})
// .use(Uppy.GoogleDrive, { target: Uppy.Dashboard, serverUrl: 'https://companion.uppy.io' })
// .use(Uppy.Dropbox, { target: Uppy.Dashboard, serverUrl: 'https://companion.uppy.io' })
// .use(Uppy.Instagram, { target: Uppy.Dashboard, serverUrl: 'https://companion.uppy.io' })
// .use(Uppy.Tus, {endpoint: 'http://localhost:1080/files/'})
.use(Uppy.AwsS3, {
getUploadParameters(file) {
// Send a request to signing endpoint.
console.log("tryna fetch /stagingputurl/" + cookie._id);
return fetch("/stagingputurl/" + cookie._id, {
method: "post",
// Send and receive JSON.
headers: {
accept: "application/json",
"content-type": "application/json"
},
body: JSON.stringify({
uid: cookie._id,
filename:
"staging/" + cookie._id + "/" + timestamp() + "_" + file.name,
contentType: file.type
})
})
.then(response => {
// Parse the JSON response.
return response.json();
})
.then(data => {
console.log("tryna parse respoonse: " + JSON.stringify(data));
// Return an object in the correct shape.
return {
method: data.method,
url: data.url,
fields: data.fields
};
});
}
});
uppy.on("complete", result => {
console.log(
"Upload complete! We’ve uploaded these files:",
result.successful
);
$.get("/staging/" + cookie._id, function(data) {
$("#staging-area").html(RenderStagedItems(data));
});
});
```
…On Mon, Jan 14, 2019 at 7:35 AM Renée Kooi ***@***.***> wrote:
Hi! could you share a code sample that reproduces the problem? I tried
uploading an extensionless file that was detected as
application/octet-stream to our aws-presigned-url
<https://github.com/transloadit/uppy/tree/master/examples/aws-presigned-url>
example, and it worked fine there.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1233 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABOMXyQLlIUW-OX_KfMktaMgf19PY3y6ks5vDIergaJpZM4ZzzjG>
.
|
|
to further clarify, the problem is with unrecognized file types, not
missing extensions - try a Blender file, for example.
Best regards,
Jim
…On Tue, Jan 15, 2019 at 11:59 AM jim cherry ***@***.***> wrote:
Hi Renée, thanks for your response - below is a script I'm using. You'll
note that I'm not using a build process, but pulling from CDN - I'll put it
on my own server for production, but I want to avoid a build process for
web. Any help appreciated!
<script>
function timestamp() {
var d = new Date();
var n = d.getTime();
return n;
}
var cookie = Cookies.get();
var uppy = Uppy.Core({
onBeforeFileAdded: (currentFile, files) => {
const modifiedFile = Object.assign(
{},
currentFile,
{ name: currentFile.name.replace(" ", "-") //clean spaces
})
uppy.info(modifiedFile);
return modifiedFile
}
})
.use(Uppy.Dashboard, {
inline: true,
target: '#drag-drop-area',
})
.use(Uppy.Webcam, {
target: Uppy.Dashboard,
modes: [
'video-audio',
'video-only',
'audio-only',
'picture'
],
mirror: true,
facingMode: 'environment',
})
// .use(Uppy.GoogleDrive, { target: Uppy.Dashboard, serverUrl: '
https://companion.uppy.io' })
// .use(Uppy.Dropbox, { target: Uppy.Dashboard, serverUrl: '
https://companion.uppy.io' })
// .use(Uppy.Instagram, { target: Uppy.Dashboard, serverUrl: '
https://companion.uppy.io' })
// .use(Uppy.Tus, {endpoint: 'http://localhost:1080/files/'})
.use(Uppy.AwsS3, {
getUploadParameters (file) {
// Send a request to signing endpoint.
console.log('tryna fetch /stagingputurl/' + cookie._id);
return fetch('/stagingputurl/' + cookie._id, {
method: 'post',
// Send and receive JSON.
headers: {
accept: 'application/json',
'content-type': 'application/json'
},
body: JSON.stringify({
uid: cookie._id,
filename: 'staging/' + cookie._id + '/' + timestamp() + '_' + file.name,
contentType: file.type
})
}).then((response) => {
// Parse the JSON response.
return response.json()
}).then((data) => {
console.log("tryna parse respoonse: " + JSON.stringify(data));
// Return an object in the correct shape.
return {
method: data.method,
url: data.url,
fields: data.fields
}
})
}
})
uppy.on('complete', (result) => {
console.log('Upload complete! We’ve uploaded these files:', result.
successful);
$.get( "/staging/" + cookie._id, function( data ) {
$( "#staging-area" ).html( RenderStagedItems(data) );
});
})
</script>
On Mon, Jan 14, 2019 at 7:35 AM Renée Kooi ***@***.***>
wrote:
> Hi! could you share a code sample that reproduces the problem? I tried
> uploading an extensionless file that was detected as
> application/octet-stream to our aws-presigned-url
> <https://github.com/transloadit/uppy/tree/master/examples/aws-presigned-url>
> example, and it worked fine there.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#1233 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABOMXyQLlIUW-OX_KfMktaMgf19PY3y6ks5vDIergaJpZM4ZzzjG>
> .
>
|
|
I also ran into this error. For some reason Uppy does not add the To fix it I explicitly set the Here is the updated S3 configuration for the aws-presigned-example: uppy.use(AwsS3, {
getUploadParameters (file) {
// Send a request to our PHP signing endpoint.
return fetch('/s3-sign.php', {
method: 'post',
// Send and receive JSON.
headers: {
accept: 'application/json',
'content-type': 'application/json'
},
body: JSON.stringify({
filename: file.name,
contentType: file.type
})
}).then((response) => {
// Parse the JSON response.
return response.json()
}).then((data) => {
// Return an object in the correct shape.
return {
method: data.method,
url: data.url,
fields: data.fields,
// Always pass the Content-Type header to avoid issues with S3
// assuming the wrong Content-Type
headers: {
"Content-Type": file.type
}
}
})
}
}) |
|
Finally getting to this 😅 right, Uppy doesn't set any content-type header, if it is there it's because the browser has decided on one. I don't know if we should set one ourselves, but we definitely should update the S3 examples with @trumpet2012's changes. It'd be good to keep doing that with presigned S3 uploads even if Uppy would set a content-type by default in the future, because you'll guarantee that the header and the signature used the same content type. |
|
This was very confusing and frustrating for us, as the main S3 example in the documentation fails out of the box in many cases, and the generic S3 error message "the signature does not match" is not very helpful in diagnosing the root cause. Some types of files like images upload successfully and other types like pdf and csv fail (because as we discovered through digging into the network tab in Chrome, a content type is attached for some file types but not others). +1 For uppy attaching a content type for S3 uploads by default, this would make the initial usage with S3 much easier. In the meantime, i've opened a pull request to update the docs here. |
* Add Content-Type header to presigned url example Prevents the main presigned url example from failing in many cases, as the browser does not assign a content type in many cases, but a content type is required by S3. Based on issue #1233 * docs: code style Co-authored-by: Renée Kooi <[email protected]>
Using uppy with presigned s3 URLs works great for me as long as it's a recognized file type, but when the detected contentType is "application/octet-stream" it always fails with a 403, "The signature we calculated does not match..." error. Any help appreciated!
The text was updated successfully, but these errors were encountered: