I f I set the CNAME to my.custom.domain.t3.storage.dev and then request a pre-signed URL (and follow the instructions on Tigris’ documentation) I end up with a URL that looks like https://my.custom.domain/bucket/object?… and I’m able to download the file.
If I set the CNAME to my.custom.domain.fly.storage.tigris.dev I get a URL that is the same as the one above (https://my.custom.domain/bucket/object?…) however I’m unable to download the file, because of a mismatch signature error.
When trying to retrieve the pre-signed download, my AmazonS3Config.ServiceUrl is https://t3.storage.devor https://fly.storage.tigris.devrespectively.
When you pointed your CNAME to Fly domain (fly.storage.tigris.dev) - did you re-generate the pre-signed URL or you used existing URL and replaced the domain?
public async Task<string> GenerateDownloadUrl(string bucketName, string objectName, int validityInSeconds = 3600, string? customDomainName = null)
{
var request = new GetPreSignedUrlRequest
{
BucketName = bucketName,
Key = objectName,
Verb = HttpVerb.GET,
Expires = DateTime.UtcNow.AddSeconds(validityInSeconds)
};
var downloadUrl = await s3Client.GetPreSignedURLAsync(request);
if (string.IsNullOrWhiteSpace(customDomainName))
return downloadUrl;
var uri = new Uri(downloadUrl);
var builder = new UriBuilder(uri)
{
Host = customDomainName,
Port = -1
};
return builder.ToString();
}
and this is the s3Client object:
var s3Client = new AmazonS3Client(
cloudStorageOptions.Value.AwsS3Options.AccessKeyId,
cloudStorageOptions.Value.AwsS3Options.SecretAccessKey,
new AmazonS3Config
{
ServiceURL = "https://t3.storage.dev",
ForcePathStyle = false,
AuthenticationRegion = "auto"
});
Basically when the ServiceUrl is https://t3.storage.dev, the pre-signed URL works, but if I change it to https://fly.storage.tigris.dev I no longer get a valid URL.
Sorry for the slow response. The code you’re using to generate pre-signed URLs looks fine. There was an issue on the Tigris side that caused pre-signed URLs generated using the fly.storage.tigris.dev endpoint to be treated as invalid by the t3.storage.dev endpoint. This issue has now been fixed. Could you please check whether everything is working as expected?