Repository navigation
Incorrect storage download link host in local #171
Description
Activity
Yup this is a known limitation supabase/cli#1079 (comment). with a temporary workaround. I will leave this issue open for tracking.
Hey @sweatybridge , gotcha. How about if in the storage client, the download link functions check if the URL contains the internal edge function
SUPABASE_URL(the kong url) used by the edge function and if it is, rewrite it to thelocalhost:54321endpoint?Perhaps a simpler alternative is to instantiate a separate
StorageClientin your edge function with url set tolocalhost:54321. For example,import { StorageClient } from '@supabase/storage-js' const STORAGE_URL = 'http://localhost:54321/storage/v1' const SERVICE_KEY = '<service_role_key>' const storageClient = new StorageClient(STORAGE_URL, { apikey: SERVICE_KEY, Authorization: `Bearer ${SERVICE_KEY}`, })
You can use this new client for creating signed urls and the original supabase-js client for other operations that target kong.
Reacted by Hector Ayala, rbkayz and Michael J. ZoidlHey @sweatybridge update: the suggested approach doesn't work, the URL has to be changed after the fact, if not the edge function client cannot find the API endpoint:
Handler error: StorageUnknownError: error sending request for url (http://localhost:54321/object/sign/public): error trying to connect: tcp connect error: Cannot assign requested address (os error 99) at https://esm.sh/v127/@supabase/storage-js@2.5.1/esnext/storage-js.mjs:2:1638 at Generator.next (<anonymous>) at u (https://esm.sh/v127/@supabase/storage-js@2.5.1/esnext/storage-js.mjs:2:1254)
I think my original approach will work and will remove the need for developers to handle this edge case any time we use the storage client in local.
I see, thanks for investigating. Let me transfer this ticket to storage-js to see if anyone can pick it up sooner.
Reacted by manolo-saotra and theconflictedfoolAny news with this? I'm facing same issue, all Signed URLs coming with "kong:8000". As a nasty workaround I created a function to search and replace for the real one but it is not ideal.
Any news with this? I'm facing same issue, all Signed URLs coming with "kong:8000". As a nasty workaround I created a function to search and replace for the real one but it is not ideal.
Did the same workaround, storage API needs improvement!
Same issue over here, any updates?
Reacted by Manuel Ángel Suárez Álvarez and Bogdan SorokaSame here!!! even in getting the public URL!
http://kong:8000/storage/v1/object/public/.......Reacted by Manuel Ángel Suárez Álvarez and Bogdan SorokaSame over here, I am using the official docker-compose and facing the same issue
Reacted by Bogdan Soroka and eyecan.ai+1, this is smelly 😄
Reacted by eyecan.aiAnother vote for this issue.
Same here
+1
This has been causing me nightmares, do I need to start developing in production
Reacted by Alberto Cubeddu // Skill Society, Lalit Kundu, Tom Whittock and Ben Kissiwhat is with this kong issue... I'm just hard coding the URL in my edge function now...
Reacted by Francesco Cretti and Tom Whittock
Describe the bug
Local edge functions run on docker inside a container called
supabase_deno_relaywhich auto-sets the SUPABASE_URL. However, it uses the internal URL of the container network. This causes issues with the JS clients that run inside edge functions with storage since it creates the download and signed URLs using the internalhttp://supabase_kong_hyperion-app:8000instead of the usual exposedlocalhost:54321api endpoint.To Reproduce
Steps to reproduce the behavior:
servecli commandhttp://supabase_kong_app:8000/storage/v1/object/public/public/users/ce5b2b2f-cfdc-4f56-a886-488dba35a184/file.txt) instead of usinglocalhost:54321Expected behavior
The download link generated is accessible locally using
localhost:54321Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):