3 ms·
> this feature is only available for authenticated users Every client is expected to provide an API key at a minimum. The API key is actually a long-lived "ano
by kiwicopple 5y ago
> this feature is only available for authenticated users
Every client is expected to provide an API key at a minimum. The API key is actually a long-lived "anon" JWT, so unauthenticated users can connect and listen to "public" changes (for example, you might want to add a table of stock prices which update every second)
> only queries the primary key
That's correct. We use PostgreSQL logical replication to capture changes, which requires PK's. This is expected for replication because otherwise there would be no way of definitely identifying an update/delete. IMO it's a good practice to add a PK to every table anyway (a simple "serial" will suffice), especially for auditing and historical analysis
- SahAssar 5y ago> IMO it's a good practice to add a PK to every table anyway (a simple "serial" will suffice), especially for auditing and historical analysis The question wasn't if a primary key was required, it was "does this also work for tables where the GRANT hides certain columns from different users?"
- kiwicopple 5y agothanks - long week. I should read more carefully. Inside a supabase project users can connect to their projects as either "anon" or "authenticated". The role information is passed inside a JWT. I'll need to confirm with Oli (asleep right now) on the technical implementation but I believe either of these roles is assumed when running the RLS checks.
- SahAssar 5y agoNo problem, totally understandable!