Passing custom headers to rpc

[CodingSoot]

I want to pass custom headers to the rpc call, along with the auth headers.
I've digged in the source code and the implementation seems trivial.

[bdlukaa]

Do you mean params?

[CodingSoot]

No. The rpc call gets converted to an HTTP Post request, with the params in its body. I'm talking about the headers of that request.

[dshukertjr]

@CodingSoot That is an interesting use case. Could I ask for more details on what you are trying to achieve ultimately here?

[CodingSoot]

I want to use Firebase Appcheck to protect the rpc calls.

On the client, before each rpc call, I should get the AppCheck token using getToken( ). This ensures the token is valid and unexpired (See docs). This token then gets sent in the headers of the rpc call.

The rpc function then calls a cloud function using http_get, which verifies that the token is valid. (See docs). If it's invalid, the rpc function stops executing.

[dshukertjr]

@CodingSoot Thanks for sharing your use case.

I am not sure if we want to add a option to set a custom headers on rpc call at the moment.

You can instead have custom backend, which will take care of calling app check endpoints and if the verification success, you can call rpc() from the backend with your Supabase service role key.

By default, rpc() functions are exposed, so you may want to edit the execute permissions on it so that anon key users cannot call it.

Let me know what you think about this workaround!

[Vinzent03]

@dshukertjr May I ask why not? Because the js SDK doesn't support it?

[dshukertjr]

@Vinzent03 Yeah, that is the main reason. What do you think about it? Should we consider adding it?

For this particular use case though, since there is already cloud function being used to verify the token, I thought it might be better to let the cloud functions handle the verification process.

BTW @CodingSoot do you not want to protect your other Postgrest routes like select() and insert()? Or is the plan to handle all of them in rpc()?

[CodingSoot]

You can instead have custom backend, which will take care of calling app check endpoints and if the verification success, you can call rpc() from the backend with your Supabase service role key.

If I want to call rpc() as if the client made the request, I can use setAuth() in the backend before making the call, right ?

BTW @CodingSoot do you not want to protect your other Postgrest routes like select() and insert()? Or is the plan to handle all of them in rpc()?

For now, I'm planning to handle of them in rpc(). I guess it would be useful if other Postgrest routes were protected too, but how would you verify the tokens then?

[dshukertjr]

@CodingSoot

If I want to call rpc() as if the client made the request, I can use setAuth() in the backend before making the call, right ?

Yup, but if you expose the RPC so that with the same permissions as the client can call them, then wouldn't that defeat the whole purpose of hiding it behind a backend to perform app check?

For now, I'm planning to handle of them in rpc(). I guess it would be useful if other Postgrest routes were protected too, but how would you verify the tokens then?

I believe there is no way to protect Postgrest routes, and that was why I asked the question!

[CodingSoot]

Yup, but if you expose the RPC so that with the same permissions as the client can call them, then wouldn't that defeat the whole purpose of hiding it behind a backend to perform app check?

Of course... I was hoping there would be a way to benefit from the RLS features with this setup. I guess the advantage of calling rpc from the client with a custom header is that we can have the rpc security set to "invoker", and thus benefit from RLS.

I believe there is no way to protect Postgrest routes, and that was why I asked the question!

Then protecting rpc would be more than enough, as we can use it for all sensitive operations.

[dshukertjr]

@CodingSoot
I think I came up with a pretty good solution!

You could create your own extension method like this to create your own customRPC call. This pretty much does the same thing as the native rpc function with a custom header!

extension on SupabaseClient {
  dynamic customRpc(
    String fn, {
    required Map<String, String> customHeaders,
    Map<String, dynamic>? params,
  }) {
    final headers = <String, String>{...customHeaders};
    final authBearer = auth.currentSession?.accessToken ?? supabaseKey;
    headers['apikey'] = supabaseKey;
    headers['Authorization'] = 'Bearer $authBearer';

    final rest = PostgrestClient(
      restUrl,
      headers: headers,
      schema: schema,
    );
    return rest.rpc(fn, params: params);
  }
}

I'm sorry for being hesitant on adding a new feature, but if we get a lot similar request, we will certainly consider adding support in our SDK, but for now, I hope this workaround is good enough!

[CodingSoot]

That's amazing, thanks !