-
-
Notifications
You must be signed in to change notification settings - Fork 55
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
Support WALRUS (Postgres RLS) Integration with Realtime Server #51
Comments
Hey @w3b6x9, Thanks for posting this! Will give this a read and reach out if needed :) |
It's been a while since this was posted. Just adding context here in case anyone ones to pick this up -- off the top of head things we need to get this in.
There are probably more tasks as well feel free to add/comment below |
We need some more discussion on the implementation of realtime-py. Imo we should only provide an async interface (because the underlying websockets stuff is inherently async). Right now we do some hacky wrap-every-async-call stuff but I think that'd just be an easy spot for bugs to arise, and if we expose that as public API we'd be obligated to provide support for it. |
That makes sense -- I'll open up a doc or a thread of sorts for further discussion |
This issue is stale because it has been open for 365 days with no activity. |
Wow this is old and I confess I don't recall the context around this - @mansueli just looping you in case relevant to the implementation of the lib |
Feature request
Is your feature request related to a problem? Please describe.
Currently, Realtime server sends all database changes to all connected clients despite Postgres Row Level Security policies. This poses security concerns when developers wish to broadcast database changes containing sensitive data to an authorized subset of connected clients based on tables with RLS enabled and row security policies.
Realtime server will integrate WALRUS (Write Ahead Log Realtime Unified Security), which means there are some changes that lib clients need to make in order to support this new security functionality.
Describe the solution you'd like
The following changes will need to be made:
user_token
when subscribing client to Realtime channel.Realtime w/ WALRUS will pass Postgres array types as [1, 2, 3], _int4, and ["a", "b", "c"], _text, instead of "{1,2,3}" (_int4/_text) so this can be forwarded without any transformations. However, clients should maintain backward compatibility so they should still be able to handle stringified Postgres array (e.g. "{1,2,3}") cases.
The changes have already been applied to
supabase-js
andrealtime-js
and their PRs can be referenced while making the necessary changes:user_token
feat: add user_token when creating realtime channel subscription supabase-community/supabase-py#270
feat: update transformers to accept already transformed walrus changes supabase-community/realtime-py#50
fix: error parsing JSON when transforming array data types supabase-community/supabase-py#113
The bug fixes include longstanding issues with transformers in
realtime-js
where range types are first JSON parsed (which results in an error sometimes due to Postgres' range exclusive and inclusive bounds) and how stringified (e.g. "{1,2,3}") array types are split (can't always split on "," in cases like _daterange). Please see PR for additional context.Additional context
We're looking to launch WALRUS in Realtime at the end of November, and all developers using the JS client will have to do is version bump their
supabase-js
to v1.2.0, which contains all the changes described above.Please reach out if there's any questions and definitely tag me to confirm PRs if you'd like! Thank you!
The text was updated successfully, but these errors were encountered: