Incorrect authorization on supabase.postgrest

[dsnopek]

After doing:

supabase.auth.sign_in(email=email, password=password)

... requests for data are still anonymous, rather than authenticated.

For example:

result = supabase.from_('table').execute();

... will apply the RLS policy with auth.uid() returning NULL.

Inspecting the headers sent, it looks like the 'Authorization' header contains "Bearer" plus my anon key, rather than the JWT access token from authenticating.

If I add this bit of code after supabase.auth.sign_in() it starts working:

supabase.postgrest.session.headers["Authorization"] = "Bearer " + supabase.auth.session().access_token

Somehow the session data isn't making it from gotrue-py over to postgrest-py?

[anand2312]

Duplicate of #185
I've gotten a bit busy since the original issue was made, so I cannot make any promises on when this will be implemented by me. Anyone is free to try implementing this, I'd be happy to review any PRs

[digital-codes]

RLS still not working. I suspect the issue is related to the following code section in superbase-py/client.py:
https://github.com/supabase-community/supabase-py/blob/develop/supabase/client.py line 200

    def _get_auth_headers(self) -> Dict[str, str]:
        """Helper method to get auth headers."""
        # What's the corresponding method to get the token
        return {
            "apiKey": self.supabase_key,
            "Authorization": f"Bearer {self.supabase_key}",
        }

This sets the bearer token to the api key, which is plain wrong when using authentication tokens ... Any ideas on this?

[J0]

Hey @digital-codes,

Thanks for the query!

Supabase introduced the concept of sessions so now on the js lib the fetch method will now make use of the access token on the session. I'll look into this when a cycle frees up or if anyone would like to take a stab at this PRs are welcome!

[J0]

Hey team,

Going to close this issue in favour of tracking on #185 which is pinned.

Do feel free to comment here if there are any other questions/concerns though.
Jo