Server.downloadFile with signed Amazon S3 URL
-
@bendurso said in Server.downloadFile with signed Amazon S3 URL:
The link contains 1359 characters. Maybe that could be the issue? Is there max limit for the link length?
Could be, I'm not sure. I believe HISE is using cURL to do the download so you can test that by running it manually in a terminal.
-
@d-healey Thanks, yes it works with curl in terminal.
In HISE, I'm clearing the HttpHeader before starting the download, as I read in the forum, and I'm making sure not to repeat the base URL (just using https://).
It works with links from other servers, but it doesn’t seem to work with signed S3 URLs.
-
@bendurso Does it work in a private browser session?
-
@d-healey yeap :)
-
@bendurso I'm stumped then... You could use cURL directly from in HISE by calling it as a process - @aaronventure posted about this a while back I think.
-
@David-Healey Thanks. It worked with cURL as a background process. I read that if the user has a Windows version prior to 2019 wont work. Should I use powershell for Windows for better compatibility right?
-
@bendurso said in Server.downloadFile with signed Amazon S3 URL:
Thanks. It worked with cURL as a background process.
I'd really like to know why it doesn't work with the standard downloadFile call.
@bendurso said in Server.downloadFile with signed Amazon S3 URL:
Should I use powershell for Windows for better compatibility right?
I don't know, I think powershell needs permissions doesn't it?
-
@David-Healey I found a post where Dan was using the same amazon s3 links as me.
https://forum.hise.audio/topic/4635/question-about-queued-downloads-from-amazon-s3/26I'm actually trying to use moonbase, but I got the same links for download.
@Dan-Korneff How did you solve this?
-
@bendurso I can't quite remember. Reading the post it seems to be related to how my webserver was redirecting the traffic. I'll take a look in the AM to see where I left off
-
@David-Healey @Dan-Korneff Great news! I was able to fix the issue with Amazon S3 pre-signed URLs and the HISE Server.downloadFile function.
Thanks to Dan's explanation of the source code (on the other post), the problem was identified:
HISE original logic sees the ? in the S3 URL and assumes it needs to separate and re-parse the query string into a separate parameter object. This process destroys the specific encoding required for the X-Amz-Signature, invalidating the S3 link.
So, I modified the ScriptingApi::Server::downloadFile function in the HISE source code to skip the parameter parsing if the URL contains the S3-specific parameter "X-Amz-Algorithm=".
I think this should be changed in the HISE source code because AWS S3 are pretty common.
-
@bendurso said in Server.downloadFile with signed Amazon S3 URL:
I think this should be changed in the HISE source code because AWS S3 are pretty common.
Is parameter splitting ever needed with a file download? Shouldn't we leave that up to the scripter to pass parameters via the parameter argument of the downloadFile function?
We could add a convenience function that converts a URL query string to a parameters object.
-
@David-Healey Haha that make sense too :)