Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow for setting Authorization and apiKey headers independently #32

Closed
zoogeny opened this issue Sep 19, 2023 · 5 comments
Closed

Allow for setting Authorization and apiKey headers independently #32

zoogeny opened this issue Sep 19, 2023 · 5 comments
Labels
enhancement New feature or request

Comments

@zoogeny
Copy link

zoogeny commented Sep 19, 2023

Feature request

Currently the TokenAuth method of the posgrest.Client struct sets both the "Authorization" header (with the token as the "Bearer") and the apikey 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:

curl 'https://sjvwsaokcugktsdaxxze.supabase.co/rest/v1/my_scores?select=*' \
-H "apikey: <ANON_KEY>" \
-H "Authorization: Bearer <ACCESS_TOKEN>"

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:

// AuthBearer sets the authorization header for subsequent requests.
func (c *Client) AuthBearer(token string) *Client {
	c.clientTransport.header.Set("Authorization", "Bearer "+token)
	return c
}

// ApiKey sets the apiKey header for subsequent requests.
func (c *Client) ApiKey(token string) *Client {
	c.clientTransport.header.Set("apikey", token)
	return c
}

Describe alternatives you've considered

When initially creating the client it is possible to set the headers independently, e.g.:

client := postgrest.NewClient(url+REST_URL, "public", map[string]string{
    "Authorization": "Bearer " + auth,
    "apikey":        auth,
})

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.

@zoogeny
Copy link
Author

zoogeny commented Sep 19, 2023

NOTE: it looks like a change to add both apiKey and Authorization header during TokenAuth calls was added as part of #21

Perhaps @Carnageous or @muratmirgun would be good candidates to review this feature request

@muratmirgun
Copy link
Member

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 💯

@whoiscarlo
Copy link
Contributor

@muratmirgun and @Carnageous I just created a PR #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 =)

@elijahmorg
Copy link
Contributor

elijahmorg commented Apr 4, 2024

@muratmirgun
#40 (comment)

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.

@elijahmorg
Copy link
Contributor

PR to add feature back. #48

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants