Recently users have reported that assets hosted on Tigris have been blocked by several ISPs due to reports of malicious content on the Tigris subdomain. We’ve been working with security vendors to get removed from these blocklists. However, the long term solution that prevents this from happening again is to make it so that the Tigris subdomain is no longer the common denominator in identifying content.
In order to make unique subdomains per bucket, we’re moving to virtual host style URLs as the default. Path name style URLs will still work for buckets created before today, but all new buckets will require a virtual host style URL. If you try to use a path name style URL with a newly created bucket, you’ll get a 403 error.
The path style URL looks like this: https://fly.storage.tigris.dev/tigris-example/bar.txt
The virtual host style URL looks like this: https://tigris-example.fly.storage.tigris.dev/bar.txt
For newly created buckets, you’ll need to configure your SDK to use virtual host style URLs. We’ve shared example code here for our most commonly used frameworks: Moving to Virtual Hosted URLs | Tigris Object Storage
Several users have reported issues with my app, specifically on pages that need to load assets from Tigris. I suspect this is the reason.
Two questions:
I’m using a custom domain for my bucket. Does this overcome the ISP blocking issue or are ISP smart enough to get the actual domain name (fly.storage.tigris.dev) under the hood and block it anyway?
How can I move my existing buckets to the new virtual host style?
The ISP blocking issue doesn’t affect custom domains.
The only thing you have to do to access buckets using the virtual host style is use a different URL for your bucket. Virtual-hosted–style URLs use the following format: https://bucket-name.fly.storage.tigris.dev/key-name. See the details in the docs.
I also want to give an update on the ISP blocking issue. As you can see in the Virus Total report here. All, but one vendor, has us marked green. The one that is still marking us red, cluster25, we have been trying to reach them for the last few weeks with no luck.
I have this bucket which was created before Feb 19. The bucket is named static.mykaraoke.video and it’s set to use a custom domain.
The new virtual host style URL doesn’t work: https://static.mykaraoke.video.fly.storage.tigris.dev/2715412-uhd_3840_2160_30fps.mp4
The old path-style works: https://fly.storage.tigris.dev/static.mykaraoke.video/2715412-uhd_3840_2160_30fps.mp4
And the custom domain one works also: https://static.mykaraoke.video/2715412-uhd_3840_2160_30fps.mp4
The new virtual-host URL is what I get on the UI when I use the “Copy URL” option so I’d expect it to work. Otherwise, make the UI smarter and give me the custom-domain URL if it’s properly set.
@empz Unfortunately the virtual hosted style access doesn’t work with dot in the bucket names. The main issue is that the SSL wildcard certificate matches only buckets that do not contain dots (. ) because dots in your bucket name create what appears to be multiple subdomain levels, which a single wildcard certificate doesn’t cover.
Looks like we missed adding this info in our docs. I will update about this limitation in our docs as well. Similarly, s3 docs calling out this limitation here: virtual-hosted-style-access
I understand. Then maybe consider removing the requirement of naming the bucket the same as the custom domain. That looks like it’s an architectural decision on Tigris that might not be really needed. I should be able to have a bucket named myawesomebucket which can be accessible via myawesomebucket.fly.storage.tigris.dev but if later I want to put a custom domain on top of it that’s whatever.mydomain.com I should be able to. It’s just a CNAME record.