Closed zoogeny closed 3 months ago
NOTE: it looks like a change to add both apiKey and Authorization header during TokenAuth calls was added as part of https://github.com/supabase-community/postgrest-go/pull/21
Perhaps @Carnageous or @muratmirgun would be good candidates to review this feature request
Hi @zoogeny I've seen your request and I'll look into it as soon as possible and get back to you. Thanks for Issue 💯
@muratmirgun and @Carnageous I just created a PR https://github.com/supabase-community/postgrest-go/pull/41 to fix this issue. I did create a breaking changed because I felt that the function TokenAuth
could be improved to be more descriptive on what it does, but if that created more issues then I'd be happy to switch it back =)
@muratmirgun https://github.com/supabase-community/postgrest-go/pull/40#issuecomment-2037996291
This feature was merged and then accidentally reverted in PR #40 - see linked comment.
I'll open a PR shortly to add it back + maybe a little documentation.
PR to add feature back. https://github.com/supabase-community/postgrest-go/pull/48
Feature request
Currently the
TokenAuth
method of theposgrest.Client
struct sets both the "Authorization" header (with the token as the "Bearer") and theapikey
header.This means, for example, that it is not possible after the client is created to customize those headers independently.
Is your feature request related to a problem? Please describe.
I am trying to leverage RLS (Row Level Security) while forwarding authenticated requests to supabase from the client through a Golang server. I set an
access_token
gained from the JS library as a cookie. I then use this cookie to update the Authorization header so that the correct RLS policies are applied to the user request.Based on the Auth policies documentation, the expected headers for RLS should be:
As seen in the above documentation, the "apiKey" header ought to be set to the ANON_KEY while the "Authorization" header ought to be set to the users
access_token
.Describe the solution you'd like
It ought to be possible to independently set these header values for the case where we need a different Authorization header compared to the apiKey.
I would suggest having two separate functions to set the headers instead of a single function as it is now. This change could be additive to maintain backwards compatibility, e.g by adding:
Describe alternatives you've considered
When initially creating the client it is possible to set the headers independently, e.g.:
However, for my use case I initialize the client with the ANON_KEY before I have decided whether or not the current API call ought to be authenticated. I would prefer to override the "Authorization" on a call-by-call basis before making the actual
Execute*
in cases where I know a user-specific access_token is required.It might also be possible to expose a generic function to set headers, although this might be considered too permissive and may lead to users accidentally setting incorrect headers.