The server action expects a name parameter, that’s why it shows the error in the browser. Calling it with ?name=file.ext added to the url should work.
Does the origin exactly match? (you could test by temporary allowing all domains with *)
What does the page show in the network tab of devtools?
Calling the server parameter doesn’t give any errors but it doesn’t work. (Wouldn’t it need the whole path to know which file to upload?). It returns this:
It looks the problem migtht be: Sha256=UNSIGNED-PAYLOAD
… the region looks wrong: us-east-1
This is part of the global S3 setting:
I forgot to mention that I had already tried using the * setting the CORS configuration:
The X-Amz-Content-Sha256=UNSIGNED-PAYLOAD is that it has no hash to validate the data integrity. The region us-east-1 is the default, it isn’t used by Digital Ocean and it I have tested it and it didn’t matter.
The url looks fine, what fails is the actual upload from the client. Does the network tab of devtools show anything, connection being disconnected or error?
I was using chrome and the failed PUTs showed Status: ‘failed’ and Response: ‘Failed to load response data’.
I’ve just tried with Firefox and the failures return a 403 and this Response message:
<?xml version="1.0" encoding="UTF-8"?><Error><Code>SignatureDoesNotMatch</Code><RequestId>tx0000000000000a2d9da8d-005fc138c1-2c412d2-ams3b</RequestId><HostId>2c412d2-ams3b-ams3-zg02</HostId></Error>
I’ve just set up an account with Lineode. I thought it might be a problem with DigitalOcean but I have the same problem. Again, I’ve checked the account details by listing buckets etc. without any problem.
The console errors include:
Access to XMLHttpRequest... has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
I tried with CORs enabled and disabled (an option on Lineode).
This last error could actually be related to the region. Some Object Storage providers don’t take into account the region(like DO) in the credential url parameter but others do(like scaleway). It might be the case for linode.
Additional info: S3 custom provider -> Add region field and make code a bit more custom provider friendly
If you choose DigitalOcean or Lineode, you can specify the region:
… but this region, as well as the default ‘us-east-1’ appear in the error message:
(but I’m not clear about the significance of this).
Try changing the credential url parameter string(us-east-1) and change it for the linode region(eu-central-1) and send it manually and see what you get(hopefully a 2xx response)
Thanks - but the request was again blocked because of CORS.
It would be good to hear from anybody who has successfully managed to upload files to DigitalOcean or Lineode.
I’m not sure if should keep trying with this, perhaps with other providers, or if there is a problem and I should just wait until there is a fix. I would prefer to use DigitalOcean if possible.
I have several tests with Digital Ocean and never had any problems uploading files. Check the response headers from the server, it is definitive a CORS issue.
Thanks. I’ll try again.
I’ve had another look at this and have new information. I thought I had tried this before, but perhaps with the wrong combination of other settings. In any case…
The upload works fine if ‘Single’ is selected; it fails with errors (as mentioned above) if ‘Multi’ is selected:
Doesn’t this mean it can’t be CORS related? I would have thought this would suggest it’s a Wappler issue, unless there are some extra settings I should make in the case of multiple file upoad, apart from choosing ‘Multi’ in the S3 upload component in App Connect.
Tested it with the multi upload and works fine for me. What are the requests shown in the network tab of devtools? It should show 3 requests for each file being uploaded, 1st request is to the api to request the signed url, the other 2 requests are for the upload to digital ocean, 1 request is 0 bytes and is the CORS check to see if request is allowed and the other is the actual upload (PUT).
I created a file including nothing but the S3 uploader, using the single upload option. This gives the results you describe:
I duplicated the file and made just one change: I selected the multi-file option. This results in:
The three requests are repeated and then this appears:
This happens every time. I’ve tried with various settings at the Digital Ocean end. Here are some of the headers, including the 403:
Doesn’t look like it is a CORS problem, the GET request is to the API to get the signed URL, the OPTIONS request is the CORS check and is successful, the PUT request is the actual upload and that fails.
A 403 status code means that credentials are incorrect, where do you get the 403 response?
The 403 responses are returned with each PUT. It’s clearer using Firefox:
The XHR message shows:
<?xml version="1.0" encoding="UTF-8"?><Error><Code>SignatureDoesNotMatch</Code><RequestId>tx0000000000000c22edab2-005fcf6f1c-2c41755-ams3b</RequestId><HostId>2c41755-ams3b-ams3-zg02</HostId></Error>
Apart from the selection of single or multi, everything else is exactly the same, so the credentials should be valid in each case.
I’ve still made no progress with this. I would be interested to hear from anyone who has had success uploading to Digital Ocean - using the multiple file option - to help point me in the right direction.
Patrick suggested the credentials might be incorrect, which would seem the most likely cause. However, given I have no problem using uploading a single file, using the same server action, I would have thought the credentials must be correct.
I would be very grateful for any suggestions. I would really like to be able to use this feature.
Problem in your last error message is that the signature doesn’t match. That can have a lot of reasons. Most common reason is an invalid/expired api key is used, you could generate a new api key and test it with that one. An other problem is that the signature expires, set expire time higher and check if the time is setup correctly on the server, if the server doesn’t have the correct time then it generates an incorrect signature.
