Hi guys,
Can you add a region field to the provider when selecting custom service?
This part of code in s3.js is not “custom provider friendly”.
I had to hardcode the region(fr-par) as it is set by defect to us-east-01 or something similar and the indexOf only handles endpoints which contain ‘amazonaws’ and not custom endpoints.
I’ve been working with backblaze and scaleway endpoints.
s3.(region).backblazeb2.com
s3.(region).scw.cloud
Bumping.
Does it give an error when you use s3.fr-par.backblazeb2.com as endpoint. From what I have tried only Amazon was returning an error when the region option was not set and the other services worked without setting it and setting an endpoint was enough.
Yes. I have it set up as you say.
Nonetheless I get a “Bad Request” when sending an OPTION request to the provider and a CORS error due to the X-Amz-Credential parameter being sent with “us-east-01” region instead of the region the provider expects.
X-Amz-Credential=SCWKRK8HJNSCZ56EDKDF/20201008/us-east-01/s3/aws4_request
Ah ok, then we will indeed need a region option that can be set. I can’t parse it out of the Endpoind since I don’t know how the url is build up, it can be different per provider.
I tried S3 in Amazon, Ocean Digital and Wasabi (custom). All working very well. Perfect
On blackbaze there is a problem in the upload because they request a parameter in the signed URL upload different than others…
Yes, same is with Amazon, they check the parameter and you get an error if the region is not correct. That’s why it has the specific code to detect amazon and extract the region from the endpoint.
In backblaze I got an error being the endpoint correct…
It is something related with parameters sent by signed upload server connect… let me check it if I will find it again
It is not that. Backblaze S3 implementation doesn’t support CORS rules yet. They don’t have an ETA to support it.
The Backblaze S3 Compatible API does not currently support the following features:
Don’t remember I m not in the office… could be… But I remember an article I read on their website about something concerning the upload… maybe I’m wrong…
[Edit]
Yes I tested again the page… CORS error !! you are right…
Hey @JonL. Are you still using this custom code? the s3.js file you mentioned, is that the file in the aws-sdk node_modules folder on Wappler’s own s3.js file?
Wappler’s fle.
Maybe this could be added in the next pass you guys do to globals?
I certainly confirmed that the custom s3 connection does work for Google, but only for some of the actions/steps.
It works fine to list the buckets and upload objects files etc, but it can’t create a bucket because of the region issue mentioned here.
It also can’t list the objects with a bucket but that’s doe to the listObjectv2 compatibility issue with Google that @patrick mentioned in my other post.
Pretty sure this fell under the cracks.
I finally found some time to undo all my custom code in the core files thanks to the past inclusion of dotenv and redis.
This is just the one thing that keeps me discarding changes in GIT with every Wappler update.
setS3Provider: function(name, options) {
options = this.parse(options);
const AWS = require('aws-sdk');
const endpoint = new AWS.Endpoint(this.parseRequired(options.endpoint, 'string', 's3.provider: endpoint is required.'));
const accessKeyId = this.parseRequired(options.accessKeyId, 'string', 's3.provider: accessKeyId is required.');
const secretAccessKey = this.parseRequired(options.secretAccessKey, 'string', 's3.provider: secretAccessKey is required.');
let region = 'fr-par';
let pos = options.endpoint.indexOf('.amazonaws');
if (pos > 3) region = options.endpoint.substr(3, pos - 3);
this.s3[name] = new AWS.S3({ endpoint, accessKeyId, secretAccessKey, region, signatureVersion: 'v4' });
return this.s3[name];
},
Could you guys add something of the sorts and the field in the UI?
let region = options.region || 'us-east-1';
I still need to manually change it to fr-par every time.
@patrick bumping this as it’s still a nuisance after 15 months and has a relatively easy fix 