https://supabase.com/ logo
Join Discord
Powered by
Is it possible to get supabase storage to persist ...
# help
l
Is it possible to get supabase storage to persist images in browser cache?
e
Hi Lawrence, that is a good catch. I have filed a bug here - https://github.com/supabase/storage-api/issues/60
The reasoning behind having create Signed URL as a POST is that it is creating a resource and GET to the same endpoint retrieves the signed object
Caching POST requests is not common yeah, but you will only create a new signed URL once and then use the GET endpoint here https://supabase.github.io/storage-api/#/object/get_object_sign__bucketName___ to retrieve the signed object multiple times after that (before it expires at least) and that should be cached by the browser
l
ah, I see. get_object_sign__bucketName__ isn't implemented in the client library yet though, right?
e
once you get the signed URL, you can store it in your application state somewhere - it is just a normal url that you can use in image tags etc
there is no extra auth required
l
if I understand correctly, caching will (eventually) be implemented for the signed url (/storage/v1/object/sign/test.jpg?token=whatever). however, if the user refreshes the page, createSignedUrl() will generate another url with a different token. in this case, would it still be possible to signal to the browser that there's a 304 hit?
e
Can you architect your app where you store the image url in a global state, if it exists, use that URL, if not make a request to createSignedURL
The storage explorer in our dashboard does something similar
Another option is to use our public bucket feature (if that fits in your security model)
We will fix the caching issue, but that still wont do what you suggest - persist different URLs to the browser cache as if it were the same URL
l
yeah, currently doing this, but it doesn't really help on page reloads without adding a bunch of complexity with localStorage, etc
Is this solvable if storage-api returns the same existing signed urls? the server could cache the jwt tokens associated with each particular signing request, so an authenticated user that requests a signed token will always receive the same URL, making it possible to return 304 hits
might be adding too much complexity for what it's worth, though
e
But signed URLs don't usually work like that. S3's signed URLs also behave the same way
the idea is to generate one-time URLs for operations which expire after sometime
m
I have a similar issue in that information built with the db via link
But my pages time out
e
yeah this is an option too
where you can create signed URLs with a long expiry and store it in your db
and the frontend picks up that URL
which API calls timeout @User? If it is a problem with a Supabase project, reach out to beta@supabase.io with your project reference and we will take a look
m
Hmmm might be difficult is the pages are served via one of my apache2 servers
I have thanks
l
So if i wanted a dashboard that serves images on different pages only for authenticated users, i'll need custom application logic that manually caches signed urls? eg. when user goes back and forth multiple times (not one-time URLs)
does s3 not cache signed urls either? is signing urls the only way to restrict image access only to authenticated users?
also this is off topic, but how much can my storage upload size be increased from 50mb?
m
Well thats the thing, my application uses the connection string
PreviousNext
Powered by