Incorrect storage download link host in local

[bombillazo]

Describe the bug
Local edge functions run on docker inside a container called supabase_deno_relay which 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 internal http://supabase_kong_hyperion-app:8000 instead of the usual exposed localhost:54321api endpoint.

To Reproduce
Steps to reproduce the behavior:

1. Run edge functions with serve cli command
2. Generate a download link using the JS client inside an edge function
3. Try to access the download link (will be in this format: http://supabase_kong_app:8000/storage/v1/object/public/public/users/ce5b2b2f-cfdc-4f56-a886-488dba35a184/file.txt) instead of using localhost:54321

Expected behavior
The download link generated is accessible locally using localhost:54321

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• Version of CLI 1.75.2
• Version of supabase-js 2.26.0

[sweatybridge]

Yup this is a known limitation supabase/cli#1079 (comment). with a temporary workaround. I will leave this issue open for tracking.

[bombillazo]

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 the localhost:54321 endpoint?

[sweatybridge]

Perhaps a simpler alternative is to instantiate a separate StorageClient in your edge function with url set to localhost: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.

[bombillazo]

Hey @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.

[sweatybridge]

I see, thanks for investigating. Let me transfer this ticket to storage-js to see if anyone can pick it up sooner.

[mogaal]

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.

[alberto-abarzua]

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!

[theconflictedfool]

Same issue over here, any updates?

[Ge6ben]

Same here!!! even in getting the public URL!

http://kong:8000/storage/v1/object/public/.......

[ManuelAngel99]

Same over here, I am using the official docker-compose and facing the same issue

[finallyblueskies]

+1, this is smelly 😄

[tideline3d]

Another vote for this issue.

[joshuacsg]

Same here

[francescocretti]

+1