Headers provided to Supabase client are not used in requests

[brattonross]

Bug report

Describe the bug

Headers passed to the supabase client upon creation are not sent as part of requests made by the client.

To Reproduce

Note: This reproduction example assumes that you are querying a storage bucket that has policies applied so that only authenticated users may read from the bucket, and that the request is being made outside of a browser environment e.g. from a Next.js API route.

1. Initialize a supabase client, passing in custom headers for the client, e.g.

import { createClient } from '@supabase/supabase-js'

const supabase = createClient(url, anonKey, {
  headers: {
    apiKey: anonKey,
    Authorization: `Bearer ${jwt}`
  }
})

2. Make a request using that client, e.g.

const result = await supabase.storage.from('avatars').download(avatarURL)

3. Observe that the request does not return the expected result, as the request made by the client does not use the Authorization header that was provided on creation

Expected behavior

Supabase client uses the headers provided in the call to createClient when making requests.

In the example above this would set the Authorization header on the request to the Storage API, allowing the server to make a request to the restricted content on behalf of the user.

Screenshots

N/A

System information

• OS: N/A
• Browser: N/A
• Version of supabase-js: 1.11.9
• Version of Node.js: 14.16.1

Additional context

This issue was created off the back of this comment, and is discussed further in that thread.

[ftonato]

Hello,

The data has been sending to the correct method _initSupabaseAuthClient but inside this method, as we can see here, we aren't using the param { headers: apiKey: 'xx', Authorization: 'xx' }.

[dabarrell]

@brattonross I'm looking at writing a PR to add in header handling for the clients, so we can pass in custom headers. I'm unclear about the example you give - passing auth headers to the storage client.

I note that the storage client is initialised here:
https://github.com/supabase/supabase-js/blob/master/src/SupabaseClient.ts#L74-L76

  get storage() {
    return new SupabaseStorageClient(this.storageUrl, this._getAuthHeaders())
  }

Which pulls the headers from _getAuthHeaders(), setting both the apikey and the Authorization headers. Was that not the case when you created this issue? and if it was the case, what's your use case for providing custom apikey/Authorization headers? Cheers!

(#218 added custom headers to the auth client - my PR will add them to the other clients as well)

[brattonross]

Hey @dabarrell, I was mainly interested in being able to pass my user's access token through to the server-side so that I could fetch data that was behind row-level security.

It has been a little while since I raised the issue, but I believe at the time I was writing a Next.js application and using Supabase as my backend. In particular I was working on a feature to allow users to create a "profile", where they could enter some basic information and upload an avatar (hence the use of the storage client).

I decided to use a server-side API call to fetch the user's avatar, because this would allow me to simplify the markup and just render an <img> tag with the src attribute set to the API route. Plus I could then make adjustments to the image on the server-side before sending the response if I ever wanted.

From memory, the issue was that _getAuthHeaders was only reading the session (this.auth.session()) to get the access token, so when this code was executed on the server-side the session would not be available, and requests would therefore always be unauthenticated.

It looks like this code may have changed since, and this comment seems to suggest that there is a way to achieve authenticated server-side requests, but I guess initializing the Supabase client with custom headers still does not work as expected in the issue description.

I hope this was useful for you, thanks